From jmrodriguez at cnio.es  Mon Mar  2 03:43:09 2009
From: jmrodriguez at cnio.es (jmrodriguez)
Date: Mon, 02 Mar 2009 09:43:09 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>	<49A486A8.1020003@cnio.es>
	<49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
Message-ID: <49AB9C1D.4090104@cnio.es>

Hi Eddie,

For me "moby-wsrf" sounds cool.
But do you mind to send me the link where RFC
says that, please? I did not find that description yet and
I would like read it.

Cheers,
J

Edward Kawas wrote:
> Another thing that I ran into today is that the HTTP header XML for polling,
> requesting results, and destroying the job need a root element. What does
> everyone think about wrapping the header as defined in the RFC with
> <moby-wsrf></moby-wsrf>?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
> Fern?ndez Gonz?lez
> Sent: February-24-09 3:46 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi everybody,
> 	yes, I also agree about no multi-line headers, because they could
> bring many
> compatibility issues, and some "clever" intermediate firewall or proxy could
> misunderstand them.
>
> 	Jos? Mar?a
>
> Edward Kawas wrote:
>   
>> Yeah, I just wanted to throw out the other option for consideration.
>>     
> Besides
>   
>> encoding/decoding overhead, there is also a doubling of the message side
>>     
> if
>   
>> we went that route. I agree, no new lines. 
>>
>> Anyone with any objections?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:57 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> I vote for strongly encouraging no new lines in the XML, and warning 
>> implementers that it might crap out if they include any. I HATE base64 
>> encoding and decoding messages!  Kind of defeats the purpose of using 
>> XML in the message in the first place...
>>
>> BTW, I can confirm after scouring the Web for info that lots of programs 
>> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
>> multi-line headers, even in the last couple of years.
>>
>> Edward Kawas wrote:
>>     
>>> You bring up a very good point. I think that we could either agree to use
>>>       
>> no
>>     
>>> new lines. 
>>>
>>> Another, less desirable, option might be to base64 encode the header... I
>>> like your idea more though (I like sitting on the fence ...)
>>>
>>> Eddie 
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:43 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> According to RFC2616, which references RFC822 section 3.1, you can 
>>> indeed have multi-line header field value, as long as each extra line 
>>> starts with some linear white space.  Otherwise it'll think a new line 
>>> is a new header (and probably a malformed one at that).  There is a 
>>> standard for "folding" and "unfolding" such multi-line headers, which 
>>> essential strips CR and LF out of the message on the receiving end.  I'm 
>>> not sure how well this folding and unfolding protocol is handled by 
>>> various servers and clients, but given that new lines will be stripped 
>>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>>> field XML value should have no new lines, for maximum likelihood of 
>>> transactional success?
>>>
>>> Edward Kawas wrote:
>>>   
>>>       
>>>> Hi Paul,
>>>>
>>>> I was thinking of just treating that XML doc as a string and placing
>>>>         
> that
>   
>>>>     
>>>>         
>>> as
>>>   
>>>       
>>>> the value for the header with key biomoby-wsrf.
>>>>
>>>> Do you think that will work?
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>>> Sent: February-24-09 10:17 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>>
>>>> Hi Eddie,
>>>>
>>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>>> document where you break down sample XML such as "Response from 
>>>> destroying the resource", how exact do you put that XML block in the 
>>>> header?  I though HTTP headers are usually name=value...
>>>>
>>>> Edward Kawas wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hello all,
>>>>>
>>>>> Attached is a draft proposal describing asynchronous post services in
>>>>>     
>>>>>       
>>>>>           
>>>> moby.
>>>>   
>>>>     
>>>>         
>>>>> It is very similar to the RFC for moby-async services, except that it
>>>>>           
> is
>   
>>>>> HTTP POST and not SOAP based.
>>>>>
>>>>> Be harsh but nice!
>>>>>
>>>>> Eddie 
>>>>>   
>>>>>
>>>>>           
> ------------------------------------------------------------------------
>   
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>     
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>   
>>>>     
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>   


-- 
Have you tried CARGO?
http://cargo2.bioinfo.cnio.es/

*********************
Jos? Manuel Rodr?guez Carrasco            e-mail: jmrodriguez at cnio.es
Tlfn:    (+34) 91 732 80 00 ext: 2256     Fax:    (+34) 91 224 69 76
Bioinformatic Unit
Spanish National Cancer Center (CNIO) http://www.cnio.es
Zip Code: 28029
Address: C/. Melchor Fern?ndez Almagro n? 3, Madrid (Spain) 


**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies.


From edward.kawas at gmail.com  Mon Mar  2 10:07:10 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 2 Mar 2009 07:07:10 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49AB9C1D.4090104@cnio.es>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>	<49A486A8.1020003@cnio.es>	<49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
	<49AB9C1D.4090104@cnio.es>
Message-ID: <49abf627.0e538c0a.1fda.62b6@mx.google.com>

I posted the link to the RDF to 

http://biordf.net/~kawas/async_post_services.pdf

It hasn?t been updated yet to include the 'no new lines in the http header'
request.

Eddie


-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of jmrodriguez
Sent: March-02-09 12:43 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi Eddie,

For me "moby-wsrf" sounds cool.
But do you mind to send me the link where RFC
says that, please? I did not find that description yet and
I would like read it.

Cheers,
J

Edward Kawas wrote:
> Another thing that I ran into today is that the HTTP header XML for
polling,
> requesting results, and destroying the job need a root element. What does
> everyone think about wrapping the header as defined in the RFC with
> <moby-wsrf></moby-wsrf>?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
> Fern?ndez Gonz?lez
> Sent: February-24-09 3:46 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi everybody,
> 	yes, I also agree about no multi-line headers, because they could
> bring many
> compatibility issues, and some "clever" intermediate firewall or proxy
could
> misunderstand them.
>
> 	Jos? Mar?a
>
> Edward Kawas wrote:
>   
>> Yeah, I just wanted to throw out the other option for consideration.
>>     
> Besides
>   
>> encoding/decoding overhead, there is also a doubling of the message side
>>     
> if
>   
>> we went that route. I agree, no new lines. 
>>
>> Anyone with any objections?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:57 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> I vote for strongly encouraging no new lines in the XML, and warning 
>> implementers that it might crap out if they include any. I HATE base64 
>> encoding and decoding messages!  Kind of defeats the purpose of using 
>> XML in the message in the first place...
>>
>> BTW, I can confirm after scouring the Web for info that lots of programs 
>> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
>> multi-line headers, even in the last couple of years.
>>
>> Edward Kawas wrote:
>>     
>>> You bring up a very good point. I think that we could either agree to
use
>>>       
>> no
>>     
>>> new lines. 
>>>
>>> Another, less desirable, option might be to base64 encode the header...
I
>>> like your idea more though (I like sitting on the fence ...)
>>>
>>> Eddie 
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:43 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> According to RFC2616, which references RFC822 section 3.1, you can 
>>> indeed have multi-line header field value, as long as each extra line 
>>> starts with some linear white space.  Otherwise it'll think a new line 
>>> is a new header (and probably a malformed one at that).  There is a 
>>> standard for "folding" and "unfolding" such multi-line headers, which 
>>> essential strips CR and LF out of the message on the receiving end.  I'm

>>> not sure how well this folding and unfolding protocol is handled by 
>>> various servers and clients, but given that new lines will be stripped 
>>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>>> field XML value should have no new lines, for maximum likelihood of 
>>> transactional success?
>>>
>>> Edward Kawas wrote:
>>>   
>>>       
>>>> Hi Paul,
>>>>
>>>> I was thinking of just treating that XML doc as a string and placing
>>>>         
> that
>   
>>>>     
>>>>         
>>> as
>>>   
>>>       
>>>> the value for the header with key biomoby-wsrf.
>>>>
>>>> Do you think that will work?
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>>> Sent: February-24-09 10:17 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>>
>>>> Hi Eddie,
>>>>
>>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>>> document where you break down sample XML such as "Response from 
>>>> destroying the resource", how exact do you put that XML block in the 
>>>> header?  I though HTTP headers are usually name=value...
>>>>
>>>> Edward Kawas wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hello all,
>>>>>
>>>>> Attached is a draft proposal describing asynchronous post services in
>>>>>     
>>>>>       
>>>>>           
>>>> moby.
>>>>   
>>>>     
>>>>         
>>>>> It is very similar to the RFC for moby-async services, except that it
>>>>>           
> is
>   
>>>>> HTTP POST and not SOAP based.
>>>>>
>>>>> Be harsh but nice!
>>>>>
>>>>> Eddie 
>>>>>   
>>>>>
>>>>>           
> ------------------------------------------------------------------------
>   
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>     
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>   
>>>>     
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>   


-- 
Have you tried CARGO?
http://cargo2.bioinfo.cnio.es/

*********************
Jos? Manuel Rodr?guez Carrasco            e-mail: jmrodriguez at cnio.es
Tlfn:    (+34) 91 732 80 00 ext: 2256     Fax:    (+34) 91 224 69 76
Bioinformatic Unit
Spanish National Cancer Center (CNIO) http://www.cnio.es
Zip Code: 28029
Address: C/. Melchor Fern?ndez Almagro n? 3, Madrid (Spain) 


**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los
ficheros adjuntos, pueden contener informaci?n protegida para el uso
exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o
cualquier otro tipo de transmisi?n por parte de otra persona que no sea el
destinatario. Si usted recibe por error este correo, se ruega comunicarlo al
remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may
contain confidential and privileged information for the sole use of the
designated recipient named above. Distribution, reproduction or any other
use of this transmission by any party other than the intended recipient is
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Fri Mar  6 09:49:21 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 6 Mar 2009 06:49:21 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49AB9C1D.4090104@cnio.es>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>	<49A486A8.1020003@cnio.es>	<49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
	<49AB9C1D.4090104@cnio.es>
Message-ID: <49b137f6.28d7720a.5387.2c38@mx.google.com>

Just pinging everyone out there to see what the opinions are on this RFC. 

Did anyone find any obvious errors or are there any objections? 

Thanks,

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of jmrodriguez
Sent: March-02-09 12:43 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi Eddie,

For me "moby-wsrf" sounds cool.
But do you mind to send me the link where RFC
says that, please? I did not find that description yet and
I would like read it.

Cheers,
J

Edward Kawas wrote:
> Another thing that I ran into today is that the HTTP header XML for
polling,
> requesting results, and destroying the job need a root element. What does
> everyone think about wrapping the header as defined in the RFC with
> <moby-wsrf></moby-wsrf>?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
> Fern?ndez Gonz?lez
> Sent: February-24-09 3:46 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi everybody,
> 	yes, I also agree about no multi-line headers, because they could
> bring many
> compatibility issues, and some "clever" intermediate firewall or proxy
could
> misunderstand them.
>
> 	Jos? Mar?a
>
> Edward Kawas wrote:
>   
>> Yeah, I just wanted to throw out the other option for consideration.
>>     
> Besides
>   
>> encoding/decoding overhead, there is also a doubling of the message side
>>     
> if
>   
>> we went that route. I agree, no new lines. 
>>
>> Anyone with any objections?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:57 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> I vote for strongly encouraging no new lines in the XML, and warning 
>> implementers that it might crap out if they include any. I HATE base64 
>> encoding and decoding messages!  Kind of defeats the purpose of using 
>> XML in the message in the first place...
>>
>> BTW, I can confirm after scouring the Web for info that lots of programs 
>> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
>> multi-line headers, even in the last couple of years.
>>
>> Edward Kawas wrote:
>>     
>>> You bring up a very good point. I think that we could either agree to
use
>>>       
>> no
>>     
>>> new lines. 
>>>
>>> Another, less desirable, option might be to base64 encode the header...
I
>>> like your idea more though (I like sitting on the fence ...)
>>>
>>> Eddie 
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:43 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> According to RFC2616, which references RFC822 section 3.1, you can 
>>> indeed have multi-line header field value, as long as each extra line 
>>> starts with some linear white space.  Otherwise it'll think a new line 
>>> is a new header (and probably a malformed one at that).  There is a 
>>> standard for "folding" and "unfolding" such multi-line headers, which 
>>> essential strips CR and LF out of the message on the receiving end.  I'm

>>> not sure how well this folding and unfolding protocol is handled by 
>>> various servers and clients, but given that new lines will be stripped 
>>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>>> field XML value should have no new lines, for maximum likelihood of 
>>> transactional success?
>>>
>>> Edward Kawas wrote:
>>>   
>>>       
>>>> Hi Paul,
>>>>
>>>> I was thinking of just treating that XML doc as a string and placing
>>>>         
> that
>   
>>>>     
>>>>         
>>> as
>>>   
>>>       
>>>> the value for the header with key biomoby-wsrf.
>>>>
>>>> Do you think that will work?
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>>> Sent: February-24-09 10:17 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>>
>>>> Hi Eddie,
>>>>
>>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>>> document where you break down sample XML such as "Response from 
>>>> destroying the resource", how exact do you put that XML block in the 
>>>> header?  I though HTTP headers are usually name=value...
>>>>
>>>> Edward Kawas wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hello all,
>>>>>
>>>>> Attached is a draft proposal describing asynchronous post services in
>>>>>     
>>>>>       
>>>>>           
>>>> moby.
>>>>   
>>>>     
>>>>         
>>>>> It is very similar to the RFC for moby-async services, except that it
>>>>>           
> is
>   
>>>>> HTTP POST and not SOAP based.
>>>>>
>>>>> Be harsh but nice!
>>>>>
>>>>> Eddie 
>>>>>   
>>>>>
>>>>>           
> ------------------------------------------------------------------------
>   
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>     
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>   
>>>>     
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>   


-- 
Have you tried CARGO?
http://cargo2.bioinfo.cnio.es/

*********************
Jos? Manuel Rodr?guez Carrasco            e-mail: jmrodriguez at cnio.es
Tlfn:    (+34) 91 732 80 00 ext: 2256     Fax:    (+34) 91 224 69 76
Bioinformatic Unit
Spanish National Cancer Center (CNIO) http://www.cnio.es
Zip Code: 28029
Address: C/. Melchor Fern?ndez Almagro n? 3, Madrid (Spain) 


**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los
ficheros adjuntos, pueden contener informaci?n protegida para el uso
exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o
cualquier otro tipo de transmisi?n por parte de otra persona que no sea el
destinatario. Si usted recibe por error este correo, se ruega comunicarlo al
remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may
contain confidential and privileged information for the sole use of the
designated recipient named above. Distribution, reproduction or any other
use of this transmission by any party other than the intended recipient is
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From MichaelGerlich at gmx.de  Tue Mar 10 19:27:38 2009
From: MichaelGerlich at gmx.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 00:27:38 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
Message-ID: <000001c9a1d7$ccf5a120$66e0e360$@de>

Hi all,

I checked out Biomoby from CVS and tried to install it via the corresponding
ant tasks, but after fetching all necessary libraries, the compilation fails
with a lot of error messages regarding datatypes SOTEST*.

I also encountered this behavior when I tried to run Moses Generator for one
of my services with an existing Biomoby instance on another machine. There
the build also fails. 
I tested this on 3 different machines, including both Ubuntu and XP os. The
error log is attached, taken from Dashboad.

Does anyone encounter similar problems? Should I try cleaning Maven
repository, Biomoby cache and/or new Eclipse workspace?

Thanks in advance and regards,
Michael


Excerpt follows (100 error messages like this):

home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot override
getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
    [javac] required: org.biomoby.shared.datatypes.SOTest2_engineered_region
    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_foreign_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
cannot override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot override
getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
cannot override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                                             ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                            


From martin.senger at gmail.com  Tue Mar 10 19:39:42 2009
From: martin.senger at gmail.com (Martin Senger)
Date: Wed, 11 Mar 2009 00:39:42 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <000001c9a1d7$ccf5a120$66e0e360$@de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
Message-ID: <4d93f07c0903101639q10f79c92wba74163dc3ace4f4@mail.gmail.com>

The problem is known and was discussed in the past. Perhaps Eddie remembers
it (because I don't) - it has something to do (I think) with not cleaning
generated MOses code, perhaps also relevant to the local cache. I will be
back on inet in couple of days - and I will try to be more helpful if the
problem is not solved until then.

Cheers,
Martin

-- 
Martin Senger
email: martin.senger at gmail.com,m.senger at cgiar.org
skype: martinsenger
Sent from: Paris J France.

From edward.kawas at gmail.com  Tue Mar 10 20:49:27 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 10 Mar 2009 17:49:27 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <000001c9a1d7$ccf5a120$66e0e360$@de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
Message-ID: <49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>

Hi Michael,

What version of JAVA are you using? What registry are you generating these
datatypes from?

Thanks,

Eddie 

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
Sent: March-10-09 4:28 PM
To: MOBY-dev at lists.open-bio.org
Subject: [MOBY-dev] error installing Biomoby via ant

Hi all,

I checked out Biomoby from CVS and tried to install it via the corresponding
ant tasks, but after fetching all necessary libraries, the compilation fails
with a lot of error messages regarding datatypes SOTEST*.

I also encountered this behavior when I tried to run Moses Generator for one
of my services with an existing Biomoby instance on another machine. There
the build also fails. 
I tested this on 3 different machines, including both Ubuntu and XP os. The
error log is attached, taken from Dashboad.

Does anyone encounter similar problems? Should I try cleaning Maven
repository, Biomoby cache and/or new Eclipse workspace?

Thanks in advance and regards,
Michael


Excerpt follows (100 error messages like this):

home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot override
getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
    [javac] required: org.biomoby.shared.datatypes.SOTest2_engineered_region
    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_foreign_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
cannot override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot override
getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
cannot override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                                             ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                            

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From mgerlich at ipb-halle.de  Wed Mar 11 07:14:14 2009
From: mgerlich at ipb-halle.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 12:14:14 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
Message-ID: <49B79D06.5090208@ipb-halle.de>

Hi Eddie,

I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
generated services and axis 1.4 and Tomcat5.5).

This problem also occurs when I run install from a fresh CVS checkout 
(including a fresh Biomoby cache directory). All SOTEST* datatypes are 
only registered at Central registry, so they are fetched when Biomoby 
fills its cache (retrieving datatypes).

Regards,

Michael

> Hi Michael,
>
> What version of JAVA are you using? What registry are you generating these
> datatypes from?
>
> Thanks,
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-10-09 4:28 PM
> To: MOBY-dev at lists.open-bio.org
> Subject: [MOBY-dev] error installing Biomoby via ant
>
> Hi all,
>
> I checked out Biomoby from CVS and tried to install it via the corresponding
> ant tasks, but after fetching all necessary libraries, the compilation fails
> with a lot of error messages regarding datatypes SOTEST*.
>
> I also encountered this behavior when I tried to run Moses Generator for one
> of my services with an existing Biomoby instance on another machine. There
> the build also fails. 
> I tested this on 3 different machines, including both Ubuntu and XP os. The
> error log is attached, taken from Dashboad.
>
> Does anyone encounter similar problems? Should I try cleaning Maven
> repository, Biomoby cache and/or new Eclipse workspace?
>
> Thanks in advance and regards,
> Michael
>
>
> Excerpt follows (100 error messages like this):
>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot override
> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_engineered_region
>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_foreign_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
> cannot override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot override
> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
> incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
> getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
> cannot override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
>     [javac]                                             ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
> override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
>     [javac]                            
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>   


-- 

Michael Gerlich
Group Bioinformatics & Mass Spectrometry
Leibniz Institute of Plant Biochemistry
06120 Halle, Germany


From edward.kawas at gmail.com  Wed Mar 11 11:40:33 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 08:40:33 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B79D06.5090208@ipb-halle.de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
Message-ID: <49b7db8a.27ba720a.09b1.ffffacef@mx.google.com>

Okay, I have the same problem right now. I deleted my cache, my repository,
etc and building datatypes still fails. I was waiting to solve the problem
before replying, but I haven't been able to figure it out. I will respond
once I do.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
Sent: March-11-09 4:14 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

Hi Eddie,

I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
generated services and axis 1.4 and Tomcat5.5).

This problem also occurs when I run install from a fresh CVS checkout 
(including a fresh Biomoby cache directory). All SOTEST* datatypes are 
only registered at Central registry, so they are fetched when Biomoby 
fills its cache (retrieving datatypes).

Regards,

Michael

> Hi Michael,
>
> What version of JAVA are you using? What registry are you generating these
> datatypes from?
>
> Thanks,
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-10-09 4:28 PM
> To: MOBY-dev at lists.open-bio.org
> Subject: [MOBY-dev] error installing Biomoby via ant
>
> Hi all,
>
> I checked out Biomoby from CVS and tried to install it via the
corresponding
> ant tasks, but after fetching all necessary libraries, the compilation
fails
> with a lot of error messages regarding datatypes SOTEST*.
>
> I also encountered this behavior when I tried to run Moses Generator for
one
> of my services with an existing Biomoby instance on another machine. There
> the build also fails. 
> I tested this on 3 different machines, including both Ubuntu and XP os.
The
> error log is attached, taken from Dashboad.
>
> Does anyone encounter similar problems? Should I try cleaning Maven
> repository, Biomoby cache and/or new Eclipse workspace?
>
> Thanks in advance and regards,
> Michael
>
>
> Excerpt follows (100 error messages like this):
>
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
override
> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>     [javac] required:
org.biomoby.shared.datatypes.SOTest2_engineered_region
>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_foreign_transposable_element.java:121:
> getMoby_has_quality() in
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
> cannot override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
override
> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
> incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
> getMoby_part_of() in
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
> cannot override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                                             ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
> override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                            
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>   


-- 

Michael Gerlich
Group Bioinformatics & Mass Spectrometry
Leibniz Institute of Plant Biochemistry
06120 Halle, Germany

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From edward.kawas at gmail.com  Wed Mar 11 13:00:29 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 10:00:29 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B79D06.5090208@ipb-halle.de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
Message-ID: <49b7ee46.02578c0a.1260.ffff816d@mx.google.com>

I think that I may have figured it out.

Using the datatype SOTest2_validated_cDNA_clone as an example, I think that
the main problem is that the datatype has 2 has relationships. It has
SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they both
have the articlename 'has_quality'.

I am sure that articlenames in Services have to be unique, but I can't find
any documentation online saying that articlenames describing relationships
in Datatypes have to be unique as well.

So, if articlenames have to be unique, then the registry inadvertently
allowed the registration of datatypes without unique articlenames for
container relationships. Alternatively, if this is allowed, then a bug was
discovered in MoSeS.

Anyone have any insight into which one is the correct scenario?
 
Eddie


-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
Sent: March-11-09 4:14 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

Hi Eddie,

I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
generated services and axis 1.4 and Tomcat5.5).

This problem also occurs when I run install from a fresh CVS checkout 
(including a fresh Biomoby cache directory). All SOTEST* datatypes are 
only registered at Central registry, so they are fetched when Biomoby 
fills its cache (retrieving datatypes).

Regards,

Michael

> Hi Michael,
>
> What version of JAVA are you using? What registry are you generating these
> datatypes from?
>
> Thanks,
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-10-09 4:28 PM
> To: MOBY-dev at lists.open-bio.org
> Subject: [MOBY-dev] error installing Biomoby via ant
>
> Hi all,
>
> I checked out Biomoby from CVS and tried to install it via the
corresponding
> ant tasks, but after fetching all necessary libraries, the compilation
fails
> with a lot of error messages regarding datatypes SOTEST*.
>
> I also encountered this behavior when I tried to run Moses Generator for
one
> of my services with an existing Biomoby instance on another machine. There
> the build also fails. 
> I tested this on 3 different machines, including both Ubuntu and XP os.
The
> error log is attached, taken from Dashboad.
>
> Does anyone encounter similar problems? Should I try cleaning Maven
> repository, Biomoby cache and/or new Eclipse workspace?
>
> Thanks in advance and regards,
> Michael
>
>
> Excerpt follows (100 error messages like this):
>
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
override
> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>     [javac] required:
org.biomoby.shared.datatypes.SOTest2_engineered_region
>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_foreign_transposable_element.java:121:
> getMoby_has_quality() in
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
> cannot override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
override
> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
> incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
> getMoby_part_of() in
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
> cannot override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                                             ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
> override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                            
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>   


-- 

Michael Gerlich
Group Bioinformatics & Mass Spectrometry
Leibniz Institute of Plant Biochemistry
06120 Halle, Germany

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From gordonp at ucalgary.ca  Wed Mar 11 13:19:59 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 11 Mar 2009 11:19:59 -0600
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
Message-ID: <49B7F2BF.2060801@ucalgary.ca>

I can confirm that member articleNames must be unique.  Otherwise there 
would be no way to distinguish two HAS and a HAS-A instance.

Edward Kawas wrote:
> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't find
> any documentation online saying that articlenames describing relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
>  
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout 
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are 
> only registered at Central registry, so they are fetched when Biomoby 
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>   
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
>>     
> corresponding
>   
>> ant tasks, but after fetching all necessary libraries, the compilation
>>     
> fails
>   
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
>>     
> one
>   
>> of my services with an existing Biomoby instance on another machine. There
>> the build also fails. 
>> I tested this on 3 different machines, including both Ubuntu and XP os.
>>     
> The
>   
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>>     
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>   
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>     
> override
>   
>> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>   
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>   
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>     
> override
>   
>> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>>     
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>   
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                                             ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                            
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>   
>>     
>
>
>   

From edward.kawas at gmail.com  Wed Mar 11 13:47:37 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 10:47:37 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B7F2BF.2060801@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
Message-ID: <49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>

Thanks Paul. Then there is a bug in the registry.

Michael, you may need to re-register your datatypes, taking into account
that articlenames must be unique. 

While I am at it, a wise man once said that "if you 'inherit' from Object
and don't add any new fields, then you have used the Object ontology
incorrectly." Hmm, actually I think Mark said this ;-)

For instance, if you have a service that consumes SOTest_DNA, do you really
mean that the service consumes DNASequence under the namespace SOTest?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: March-11-09 10:20 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

I can confirm that member articleNames must be unique.  Otherwise there 
would be no way to distinguish two HAS and a HAS-A instance.

Edward Kawas wrote:
> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't
find
> any documentation online saying that articlenames describing relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
>  
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout 
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are 
> only registered at Central registry, so they are fetched when Biomoby 
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>   
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating
these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
>>     
> corresponding
>   
>> ant tasks, but after fetching all necessary libraries, the compilation
>>     
> fails
>   
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
>>     
> one
>   
>> of my services with an existing Biomoby instance on another machine.
There
>> the build also fails. 
>> I tested this on 3 different machines, including both Ubuntu and XP os.
>>     
> The
>   
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>>     
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>   
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>     
> override
>   
>> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>   
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>   
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_foreign_transposable_element.java:112:
getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>     
> override
>   
>> getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>   
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                                             ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                            
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>   
>>     
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From markw at illuminae.com  Wed Mar 11 13:43:41 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 10:43:41 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
Message-ID: <op.uqm163nqnbznux@mark.ubic.ubc.ca>

I believe that the MOBY Central code is supposed to check that  
articlenames are unique... but it may be bugged!

M



On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:

> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think  
> that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they  
> both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't  
> find
> any documentation online saying that articlenames describing  
> relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug  
> was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
> only registered at Central registry, so they are fetched when Biomoby
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating  
>> these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
> corresponding
>> ant tasks, but after fetching all necessary libraries, the compilation
> fails
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
> one
>> of my services with an existing Biomoby instance on another machine.  
>> There
>> the build also fails.
>> I tested this on 3 different machines, including both Ubuntu and XP os.
> The
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
> override
>> getMoby_Parent() in  
>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_foreign_transposable_element.java:112:  
>> getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
> override
>> getMoby_has_quality() in  
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]                                             ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>> cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>
>



From markw at illuminae.com  Wed Mar 11 14:07:10 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 11:07:10 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
	<49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>
Message-ID: <op.uqm298hqnbznux@mark.ubic.ubc.ca>

On Wed, 11 Mar 2009 10:47:37 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:


> While I am at it, a wise man once said that "if you 'inherit' from Object
> and don't add any new fields, then you have used the Object ontology
> incorrectly." Hmm, actually I think Mark said this ;-)


Yes, I did... and I still believe it!  The "exception" is with the  
IRRI/GCP objects, but they have willingly accepted the limitations to  
interoperability that this decision creates.


> For instance, if you have a service that consumes SOTest_DNA, do you  
> really
> mean that the service consumes DNASequence under the namespace SOTest?


Without even LOOKING at the service, I bet my first-born that Eddie is  
right...  The confusion of object and namespace is quite common,  
unfortunately :-(

M

From edward.kawas at gmail.com  Wed Mar 11 14:08:51 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 11:08:51 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm298hqnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>
	<op.uqm298hqnbznux@mark.ubic.ubc.ca>
Message-ID: <49b7fe4c.25bb720a.2b7c.ffffb0ec@mx.google.com>

So just to be clear, right now there aren't any services registered that use
those datatypes. I was just throwing out an assumption.

Thanks for betting the first born ;-)

Eddie


-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 11:07 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

On Wed, 11 Mar 2009 10:47:37 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:


> While I am at it, a wise man once said that "if you 'inherit' from Object
> and don't add any new fields, then you have used the Object ontology
> incorrectly." Hmm, actually I think Mark said this ;-)


Yes, I did... and I still believe it!  The "exception" is with the  
IRRI/GCP objects, but they have willingly accepted the limitations to  
interoperability that this decision creates.


> For instance, if you have a service that consumes SOTest_DNA, do you  
> really
> mean that the service consumes DNASequence under the namespace SOTest?


Without even LOOKING at the service, I bet my first-born that Eddie is  
right...  The confusion of object and namespace is quite common,  
unfortunately :-(

M
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From MichaelGerlich at gmx.de  Wed Mar 11 14:21:08 2009
From: MichaelGerlich at gmx.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 19:21:08 +0100
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm163nqnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
Message-ID: <001e01c9a276$283878c0$78a96a40$@de>

Hi,

those datatypes are neither mine nor do I use them. 
They are registered at some French site. I don't use any of these SOTEST*
datatypes. 
I just can't get a fresh Biomoby checkout "installed" correctly or generate
Moses code for one of my services (using pre-defined datatypes like
ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel, which
is derived from Array and having unique field names ;) ).

Is there a way to circumvent these SOTEST* datatypes when running Moses
and/or install ant script?

Kind regards,
Michael



-----Urspr?ngliche Nachricht-----
Von: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark Wilkinson
Gesendet: Mittwoch, 11. M?rz 2009 18:44
An: Core developer announcements
Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

I believe that the MOBY Central code is supposed to check that  
articlenames are unique... but it may be bugged!

M



On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:

> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think  
> that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they  
> both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't  
> find
> any documentation online saying that articlenames describing  
> relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug  
> was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
> only registered at Central registry, so they are fetched when Biomoby
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating  
>> these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
> corresponding
>> ant tasks, but after fetching all necessary libraries, the compilation
> fails
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
> one
>> of my services with an existing Biomoby instance on another machine.  
>> There
>> the build also fails.
>> I tested this on 3 different machines, including both Ubuntu and XP os.
> The
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
> override
>> getMoby_Parent() in  
>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_foreign_transposable_element.java:112:  
>> getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
> override
>> getMoby_has_quality() in  
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]                                             ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>> cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>
>


_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Wed Mar 11 14:31:59 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 11:31:59 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <001e01c9a276$283878c0$78a96a40$@de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
	<001e01c9a276$283878c0$78a96a40$@de>
Message-ID: <op.uqm4flhynbznux@mark.ubic.ubc.ca>

Eddie, if no service uses them, and if no object uses them, then we should  
probably consider deleting them...  this is allowed by the API.

M



On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich  
<MichaelGerlich at gmx.de> wrote:

> Hi,
>
> those datatypes are neither mine nor do I use them.
> They are registered at some French site. I don't use any of these SOTEST*
> datatypes.
> I just can't get a fresh Biomoby checkout "installed" correctly or  
> generate
> Moses code for one of my services (using pre-defined datatypes like
> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,  
> which
> is derived from Array and having unique field names ;) ).
>
> Is there a way to circumvent these SOTEST* datatypes when running Moses
> and/or install ant script?
>
> Kind regards,
> Michael
>
>
>
> -----Urspr?ngliche Nachricht-----
> Von: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark  
> Wilkinson
> Gesendet: Mittwoch, 11. M?rz 2009 18:44
> An: Core developer announcements
> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>
> I believe that the MOBY Central code is supposed to check that
> articlenames are unique... but it may be bugged!
>
> M
>
>
>
> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>
> wrote:
>
>> I think that I may have figured it out.
>>
>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>> the main problem is that the datatype has 2 has relationships. It has
>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>> have the articlename 'has_quality'.
>>
>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>> any documentation online saying that articlenames describing
>> relationships
>> in Datatypes have to be unique as well.
>>
>> So, if articlenames have to be unique, then the registry inadvertently
>> allowed the registration of datatypes without unique articlenames for
>> container relationships. Alternatively, if this is allowed, then a bug
>> was
>> discovered in MoSeS.
>>
>> Anyone have any insight into which one is the correct scenario?
>> Eddie
>>
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-11-09 4:14 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi Eddie,
>>
>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>> generated services and axis 1.4 and Tomcat5.5).
>>
>> This problem also occurs when I run install from a fresh CVS checkout
>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>> only registered at Central registry, so they are fetched when Biomoby
>> fills its cache (retrieving datatypes).
>>
>> Regards,
>>
>> Michael
>>
>>> Hi Michael,
>>>
>>> What version of JAVA are you using? What registry are you generating
>>> these
>>> datatypes from?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>> Gerlich
>>> Sent: March-10-09 4:28 PM
>>> To: MOBY-dev at lists.open-bio.org
>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi all,
>>>
>>> I checked out Biomoby from CVS and tried to install it via the
>> corresponding
>>> ant tasks, but after fetching all necessary libraries, the compilation
>> fails
>>> with a lot of error messages regarding datatypes SOTEST*.
>>>
>>> I also encountered this behavior when I tried to run Moses Generator  
>>> for
>> one
>>> of my services with an existing Biomoby instance on another machine.
>>> There
>>> the build also fails.
>>> I tested this on 3 different machines, including both Ubuntu and XP os.
>> The
>>> error log is attached, taken from Dashboad.
>>>
>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>
>>> Thanks in advance and regards,
>>> Michael
>>>
>>>
>>> Excerpt follows (100 error messages like this):
>>>
>>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>> override
>>> getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>     [javac] required:
>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>> getMoby_has_quality() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>> cannot override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_foreign_transposable_element.java:112:
>>> getMoby_has_quality()
>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>> override
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>> incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_transposable_element.java:121:
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>> getMoby_part_of() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>> cannot override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]                                             ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>> cannot
>>> override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Wed Mar 11 14:32:11 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 11:32:11 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm4flhynbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>
	<op.uqm4flhynbznux@mark.ubic.ubc.ca>
Message-ID: <49b803c4.1a36720a.27ca.ffff822e@mx.google.com>

I feel bad doing so, but ok. I will back up their definitions and then remove them.

When I am done, I will let everyone know.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 11:32 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Eddie, if no service uses them, and if no object uses them, then we should  
probably consider deleting them...  this is allowed by the API.

M



On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich  
<MichaelGerlich at gmx.de> wrote:

> Hi,
>
> those datatypes are neither mine nor do I use them.
> They are registered at some French site. I don't use any of these SOTEST*
> datatypes.
> I just can't get a fresh Biomoby checkout "installed" correctly or  
> generate
> Moses code for one of my services (using pre-defined datatypes like
> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,  
> which
> is derived from Array and having unique field names ;) ).
>
> Is there a way to circumvent these SOTEST* datatypes when running Moses
> and/or install ant script?
>
> Kind regards,
> Michael
>
>
>
> -----Urspr?ngliche Nachricht-----
> Von: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark  
> Wilkinson
> Gesendet: Mittwoch, 11. M?rz 2009 18:44
> An: Core developer announcements
> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>
> I believe that the MOBY Central code is supposed to check that
> articlenames are unique... but it may be bugged!
>
> M
>
>
>
> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>
> wrote:
>
>> I think that I may have figured it out.
>>
>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>> the main problem is that the datatype has 2 has relationships. It has
>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>> have the articlename 'has_quality'.
>>
>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>> any documentation online saying that articlenames describing
>> relationships
>> in Datatypes have to be unique as well.
>>
>> So, if articlenames have to be unique, then the registry inadvertently
>> allowed the registration of datatypes without unique articlenames for
>> container relationships. Alternatively, if this is allowed, then a bug
>> was
>> discovered in MoSeS.
>>
>> Anyone have any insight into which one is the correct scenario?
>> Eddie
>>
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-11-09 4:14 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi Eddie,
>>
>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>> generated services and axis 1.4 and Tomcat5.5).
>>
>> This problem also occurs when I run install from a fresh CVS checkout
>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>> only registered at Central registry, so they are fetched when Biomoby
>> fills its cache (retrieving datatypes).
>>
>> Regards,
>>
>> Michael
>>
>>> Hi Michael,
>>>
>>> What version of JAVA are you using? What registry are you generating
>>> these
>>> datatypes from?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>> Gerlich
>>> Sent: March-10-09 4:28 PM
>>> To: MOBY-dev at lists.open-bio.org
>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi all,
>>>
>>> I checked out Biomoby from CVS and tried to install it via the
>> corresponding
>>> ant tasks, but after fetching all necessary libraries, the compilation
>> fails
>>> with a lot of error messages regarding datatypes SOTEST*.
>>>
>>> I also encountered this behavior when I tried to run Moses Generator  
>>> for
>> one
>>> of my services with an existing Biomoby instance on another machine.
>>> There
>>> the build also fails.
>>> I tested this on 3 different machines, including both Ubuntu and XP os.
>> The
>>> error log is attached, taken from Dashboad.
>>>
>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>
>>> Thanks in advance and regards,
>>> Michael
>>>
>>>
>>> Excerpt follows (100 error messages like this):
>>>
>>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>> override
>>> getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>     [javac] required:
>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>> getMoby_has_quality() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>> cannot override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_foreign_transposable_element.java:112:
>>> getMoby_has_quality()
>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>> override
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>> incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_transposable_element.java:121:
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>> getMoby_part_of() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>> cannot override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]                                             ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>> cannot
>>> override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev


_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Wed Mar 11 14:38:39 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 11:38:39 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
	<001e01c9a276$283878c0$78a96a40$@de>
	<op.uqm4flhynbznux@mark.ubic.ubc.ca>
	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
Message-ID: <op.uqm4qprnnbznux@mark.ubic.ubc.ca>

No need to feel bad!  This is *precisely* how Moby ontology curation is  
supposed to work!  Objects that are not being used, or that have a  
"better" object defined elsewhere in the ontology, should be deleted by  
the author of the object, or by anyone who finds it.  This is the Web 2.0  
aspect of Moby that hasn't really been working well (probably because  
everyone feels the same as you about deleting other people's stuff...).   
The API prevents you from deleting objects that *are* being used, but  
that's the only security we guarantee in Moby.

M



On Wed, 11 Mar 2009 11:32:11 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:

> I feel bad doing so, but ok. I will back up their definitions and then  
> remove them.
>
> When I am done, I will let everyone know.
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org  
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
> Sent: March-11-09 11:32 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>
> Eddie, if no service uses them, and if no object uses them, then we  
> should
> probably consider deleting them...  this is allowed by the API.
>
> M
>
>
>
> On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich
> <MichaelGerlich at gmx.de> wrote:
>
>> Hi,
>>
>> those datatypes are neither mine nor do I use them.
>> They are registered at some French site. I don't use any of these  
>> SOTEST*
>> datatypes.
>> I just can't get a fresh Biomoby checkout "installed" correctly or
>> generate
>> Moses code for one of my services (using pre-defined datatypes like
>> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,
>> which
>> is derived from Array and having unique field names ;) ).
>>
>> Is there a way to circumvent these SOTEST* datatypes when running Moses
>> and/or install ant script?
>>
>> Kind regards,
>> Michael
>>
>>
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark
>> Wilkinson
>> Gesendet: Mittwoch, 11. M?rz 2009 18:44
>> An: Core developer announcements
>> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>>
>> I believe that the MOBY Central code is supposed to check that
>> articlenames are unique... but it may be bugged!
>>
>> M
>>
>>
>>
>> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas  
>> <edward.kawas at gmail.com>
>> wrote:
>>
>>> I think that I may have figured it out.
>>>
>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>> that
>>> the main problem is that the datatype has 2 has relationships. It has
>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>> both
>>> have the articlename 'has_quality'.
>>>
>>> I am sure that articlenames in Services have to be unique, but I can't
>>> find
>>> any documentation online saying that articlenames describing
>>> relationships
>>> in Datatypes have to be unique as well.
>>>
>>> So, if articlenames have to be unique, then the registry inadvertently
>>> allowed the registration of datatypes without unique articlenames for
>>> container relationships. Alternatively, if this is allowed, then a bug
>>> was
>>> discovered in MoSeS.
>>>
>>> Anyone have any insight into which one is the correct scenario?
>>> Eddie
>>>
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>> Gerlich
>>> Sent: March-11-09 4:14 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi Eddie,
>>>
>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>> generated services and axis 1.4 and Tomcat5.5).
>>>
>>> This problem also occurs when I run install from a fresh CVS checkout
>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>> only registered at Central registry, so they are fetched when Biomoby
>>> fills its cache (retrieving datatypes).
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>> Hi Michael,
>>>>
>>>> What version of JAVA are you using? What registry are you generating
>>>> these
>>>> datatypes from?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>> Gerlich
>>>> Sent: March-10-09 4:28 PM
>>>> To: MOBY-dev at lists.open-bio.org
>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi all,
>>>>
>>>> I checked out Biomoby from CVS and tried to install it via the
>>> corresponding
>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>> fails
>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>
>>>> I also encountered this behavior when I tried to run Moses Generator
>>>> for
>>> one
>>>> of my services with an existing Biomoby instance on another machine.
>>>> There
>>>> the build also fails.
>>>> I tested this on 3 different machines, including both Ubuntu and XP  
>>>> os.
>>> The
>>>> error log is attached, taken from Dashboad.
>>>>
>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>
>>>> Thanks in advance and regards,
>>>> Michael
>>>>
>>>>
>>>> Excerpt follows (100 error messages like this):
>>>>
>>>>
>>>
>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>> override
>>>> getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>> attempting to use incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>     [javac] required:
>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>>> cannot override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>> attempting
>>>> to
>>>> use incompatible return type
>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>     [javac]                              ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>> getMoby_has_quality()
>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>> cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>> attempting
>>>> to
>>>> use incompatible return type
>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>     [javac]                              ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality()  
>>>> in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>> override
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>> attempting to use incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()
>>>> in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>> incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>> cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>> attempting
>>>> to
>>>> use incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>> getMoby_part_of() in
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>>> cannot override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>> use
>>>> incompatible return type
>>>>     [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>     [javac] required:  
>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>> getMoby_part_of()
>>> {
>>>>     [javac]                                             ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_five_prime_exon_coding_region.java:114:  
>>>> getMoby_part_of()
>>>> in
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>>> cannot
>>>> override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>> use
>>>> incompatible return type
>>>>     [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>     [javac] required:  
>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>> getMoby_part_of()
>>> {
>>>>     [javac]
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev



From gordonp at ucalgary.ca  Wed Mar 11 15:04:57 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 11 Mar 2009 13:04:57 -0600
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm4qprnnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>	<op.uqm4flhynbznux@mark.ubic.ubc.ca>	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
	<op.uqm4qprnnbznux@mark.ubic.ubc.ca>
Message-ID: <49B80B59.2010204@ucalgary.ca>

Mark,

Hopefully we can find to the time next week to purge it a bit...

Mark Wilkinson wrote:
> No need to feel bad!  This is *precisely* how Moby ontology curation 
> is supposed to work!  Objects that are not being used, or that have a 
> "better" object defined elsewhere in the ontology, should be deleted 
> by the author of the object, or by anyone who finds it.  This is the 
> Web 2.0 aspect of Moby that hasn't really been working well (probably 
> because everyone feels the same as you about deleting other people's 
> stuff...).  The API prevents you from deleting objects that *are* 
> being used, but that's the only security we guarantee in Moby.
>
> M
>
>
>
> On Wed, 11 Mar 2009 11:32:11 -0700, Edward Kawas 
> <edward.kawas at gmail.com> wrote:
>
>> I feel bad doing so, but ok. I will back up their definitions and 
>> then remove them.
>>
>> When I am done, I will let everyone know.
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org 
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
>> Sent: March-11-09 11:32 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>>
>> Eddie, if no service uses them, and if no object uses them, then we 
>> should
>> probably consider deleting them...  this is allowed by the API.
>>
>> M
>>
>>
>>
>> On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich
>> <MichaelGerlich at gmx.de> wrote:
>>
>>> Hi,
>>>
>>> those datatypes are neither mine nor do I use them.
>>> They are registered at some French site. I don't use any of these 
>>> SOTEST*
>>> datatypes.
>>> I just can't get a fresh Biomoby checkout "installed" correctly or
>>> generate
>>> Moses code for one of my services (using pre-defined datatypes like
>>> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,
>>> which
>>> is derived from Array and having unique field names ;) ).
>>>
>>> Is there a way to circumvent these SOTEST* datatypes when running Moses
>>> and/or install ant script?
>>>
>>> Kind regards,
>>> Michael
>>>
>>>
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark
>>> Wilkinson
>>> Gesendet: Mittwoch, 11. M?rz 2009 18:44
>>> An: Core developer announcements
>>> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>>>
>>> I believe that the MOBY Central code is supposed to check that
>>> articlenames are unique... but it may be bugged!
>>>
>>> M
>>>
>>>
>>>
>>> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas 
>>> <edward.kawas at gmail.com>
>>> wrote:
>>>
>>>> I think that I may have figured it out.
>>>>
>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>>> that
>>>> the main problem is that the datatype has 2 has relationships. It has
>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>>> both
>>>> have the articlename 'has_quality'.
>>>>
>>>> I am sure that articlenames in Services have to be unique, but I can't
>>>> find
>>>> any documentation online saying that articlenames describing
>>>> relationships
>>>> in Datatypes have to be unique as well.
>>>>
>>>> So, if articlenames have to be unique, then the registry inadvertently
>>>> allowed the registration of datatypes without unique articlenames for
>>>> container relationships. Alternatively, if this is allowed, then a bug
>>>> was
>>>> discovered in MoSeS.
>>>>
>>>> Anyone have any insight into which one is the correct scenario?
>>>> Eddie
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>> Gerlich
>>>> Sent: March-11-09 4:14 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi Eddie,
>>>>
>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>
>>>> This problem also occurs when I run install from a fresh CVS checkout
>>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>>> only registered at Central registry, so they are fetched when Biomoby
>>>> fills its cache (retrieving datatypes).
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> What version of JAVA are you using? What registry are you generating
>>>>> these
>>>>> datatypes from?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eddie
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>>> Gerlich
>>>>> Sent: March-10-09 4:28 PM
>>>>> To: MOBY-dev at lists.open-bio.org
>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>> corresponding
>>>>> ant tasks, but after fetching all necessary libraries, the 
>>>>> compilation
>>>> fails
>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>
>>>>> I also encountered this behavior when I tried to run Moses Generator
>>>>> for
>>>> one
>>>>> of my services with an existing Biomoby instance on another machine.
>>>>> There
>>>>> the build also fails.
>>>>> I tested this on 3 different machines, including both Ubuntu and 
>>>>> XP os.
>>>> The
>>>>> error log is attached, taken from Dashboad.
>>>>>
>>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>
>>>>> Thanks in advance and regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Excerpt follows (100 error messages like this):
>>>>>
>>>>>
>>>>
>>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat 
>>>
>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>> override
>>>>> getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>> attempting to use incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>     [javac] required:
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>>
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element 
>>>
>>>>> cannot override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>> to
>>>>> use incompatible return type
>>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>     [javac]                              ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>> getMoby_has_quality()
>>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>> cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>> to
>>>>> use incompatible return type
>>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>     [javac]                              ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>> override
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>>> attempting to use incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>>> getMoby_has_quality()
>>>>> in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>>> incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>> cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>> to
>>>>> use incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>> getMoby_part_of() in
>>>>>
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region 
>>>
>>>>> cannot override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>>> use
>>>>> incompatible return type
>>>>>     [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>     [javac] required: 
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>> {
>>>>>     [javac]                                             ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>>> getMoby_part_of()
>>>>> in
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>>>> cannot
>>>>> override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>>> use
>>>>> incompatible return type
>>>>>     [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>     [javac] required: 
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>> {
>>>>>     [javac]
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

From markw at illuminae.com  Wed Mar 11 15:39:43 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 12:39:43 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49B80B59.2010204@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
	<001e01c9a276$283878c0$78a96a40$@de>
	<op.uqm4flhynbznux@mark.ubic.ubc.ca>
	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
	<op.uqm4qprnnbznux@mark.ubic.ubc.ca> <49B80B59.2010204@ucalgary.ca>
Message-ID: <op.uqm7khipnbznux@mark.ubic.ubc.ca>

Amen!


On Wed, 11 Mar 2009 12:04:57 -0700, Paul Gordon <gordonp at ucalgary.ca>  
wrote:

> Mark,
>
> Hopefully we can find to the time next week to purge it a bit...

From edward.kawas at gmail.com  Wed Mar 11 15:55:41 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 12:55:41 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm7khipnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>	<op.uqm4flhynbznux@mark.ubic.ubc.ca>	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>	<op.uqm4qprnnbznux@mark.ubic.ubc.ca>
	<49B80B59.2010204@ucalgary.ca> <op.uqm7khipnbznux@mark.ubic.ubc.ca>
Message-ID: <49b81757.25578c0a.5a64.ffffa22a@mx.google.com>

Okay, I finally have removed all of the datatypes. I have a backup of them
all (1400 or so datatypes ...)

Dashboard seems to be happy again and MOSES generates everything
successfully.

Make sure to remove the files in the moby-live/Java/generated/ folder and
try again.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 12:40 PM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Amen!


On Wed, 11 Mar 2009 12:04:57 -0700, Paul Gordon <gordonp at ucalgary.ca>  
wrote:

> Mark,
>
> Hopefully we can find to the time next week to purge it a bit...
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From MichaelGerlich at gmx.de  Wed Mar 11 18:31:34 2009
From: MichaelGerlich at gmx.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 23:31:34 +0100
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b81757.25578c0a.5a64.ffffa22a@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>	<op.uqm4flhynbznux@mark.ubic.ubc.ca>	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>	<op.uqm4qprnnbznux@mark.ubic.ubc.ca>	<49B80B59.2010204@ucalgary.ca>
	<op.uqm7khipnbznux@mark.ubic.ubc.ca>
	<49b81757.25578c0a.5a64.ffffa22a@mx.google.com>
Message-ID: <000901c9a299$23095540$691bffc0$@de>

[Success] 
  [Success] Installation completed.
  [Success] 
  [Success] Thanks for any comments and suggestions
  [Success] (moby-l at biomoby.org or moby-dev at biomoby.org)
  [Success]   

Just what I wanted to see - thanks for your efforts ;-)

Greetings,
Michael


-----Urspr?ngliche Nachricht-----
Von: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Edward Kawas
Gesendet: Mittwoch, 11. M?rz 2009 20:56
An: 'Core developer announcements'
Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Okay, I finally have removed all of the datatypes. I have a backup of them
all (1400 or so datatypes ...)

Dashboard seems to be happy again and MOSES generates everything
successfully.

Make sure to remove the files in the moby-live/Java/generated/ folder and
try again.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 12:40 PM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Amen!


On Wed, 11 Mar 2009 12:04:57 -0700, Paul Gordon <gordonp at ucalgary.ca>  
wrote:

> Mark,
>
> Hopefully we can find to the time next week to purge it a bit...
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From Sebastien.Carrere at toulouse.inra.fr  Tue Mar 24 05:27:24 2009
From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Tue, 24 Mar 2009 10:27:24 +0100
Subject: [MOBY-dev] primitive datatype: Password
Message-ID: <49C8A77C.1010104@toulouse.inra.fr>

Bonjour a tous,

What do you think about setting a new primitive datatype "Password" in 
addition to "String", "Integer", "DateTime", "Float", "Boolean"?

We plan to use secondary inputs to control some web-services access 
(using login/password).
Defining such a primitive datatype for parameters could be usefull for 
web interface: we could deal with this kind of parameters as we do with 
password fields in HTML forms.

What is your point of view ?

Merci,

Sebastien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sebastien_Carrere.vcf
Type: text/x-vcard
Size: 387 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090324/b9443237/attachment-0001.vcf>

From dmitry.repchevski at bsc.es  Tue Mar 24 15:13:25 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 12:13:25 -0700
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <49C8A77C.1010104@toulouse.inra.fr>
References: <49C8A77C.1010104@toulouse.inra.fr>
Message-ID: <49C930D5.70402@bsc.es>

I think this is a bad idea...

Moby primitive types are exactly that - "primitive", no any hint of it's
usage is given.
More, since Moby uses XML as a serialization this is a subset of schema
datatype (or at least intended to be?).
Extending basic Moby datatypes is not that easy, because all the
packages must be updated to support it.
For months I've been promised by my colleagues to include "Binary" type
to be able to pass base64 directly...
http://lists.open-bio.org/pipermail/moby-dev/2008-November/005382.html

Best regards,

Dmitry




From srramirez at uma.es  Tue Mar 24 08:41:25 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Mar 2009 13:41:25 +0100
Subject: [MOBY-dev] WSDL parsing library
Message-ID: <49C8D4F5.10104@uma.es>

Hello to all the mobiers,

I'm doing a little experiment with WSDL and I have found some problems 
with the libraries for parsing it. I have tried wsdl4j, wsif and wooden.

Does anyone knows a good library for make this?

Thanks in advance.
Sergio.

-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 


From pieter.neerincx at gmail.com  Tue Mar 24 09:06:57 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Tue, 24 Mar 2009 14:06:57 +0100
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <49C8A77C.1010104@toulouse.inra.fr>
References: <49C8A77C.1010104@toulouse.inra.fr>
Message-ID: <203FDC18-6B4B-46D5-8CB2-493D769F576A@gmail.com>

Hi Sebastian,

Just a few comments/thoughts:

1. There is already a password datatype in the object ontology that  
you can use... It's not a primitive, but I don't see why it would have  
to be. It currently simply inherits from Object. Hence Password ISA  
Object. (There has been some discussion on wether or not to create  
more specialised objects without adding any children, but Password has  
been around for several years now...)

2. Secondaries are something different than Primitives. The Primitives  
are always (part of) primary inputs or outputs and the primitives are  
therefore part of the object ontology. Note that secondary inputs or  
outputs are not part of the object ontology. The secondaries do come  
in exactly the same flavors as the primitives: "String", "Integer",  
"DateTime", "Float", "Boolean". So I can understand the confusion...

Hence with what is currently available you can already use:
* A Password object as primary input.
* A String primitive with the articleName attribute password or  
something similar.
* A secondary input of type String with the articleName attribute  
password or something similar.

There are several services that use similar constructs. They all work  
just fine. The only problem is that there is no standardised mechanism  
for authentication in BioMoby, which is not so user friendly.... A  
standardised mechanism would be nice and having a password and  
optional login/accountname as primaries or secondaries makes sense to  
me. All we would have to do is agree on the object (for primaries) or  
type (for secondaries) and articleName for these.... Theoretically a  
secondary input is optional and a client should be able to leave it  
out. Most secured services will require a password though, so one can  
argue that passwords and logins must be primary inputs. I don't think  
it matters too much. As long as we standardise on something it would  
make it easier for clients to figure out how to do authentication.

There are several people who will probably suggest to handle logins  
and password on a different level. You can do it on the transport  
level, on the web server level, in the SOAP layer or you could use  
WSRF et al. Some of these would be theoretically more elegant, but  
they usually cause more overhead and more time to implement. Doing it  
in BioMoby ourselves is peanuts and gives us more control on how to do  
it: no external dependancies, libraries, etc. So I think handling  
authentication in BioMoby is the more pragmatic solution. My services  
use the Password object for several years now: it was easy to  
implement and works just fine :)

Cheers,

Pi


On 24?Mar?2009, at 10:27 AM, Sebastien Carrere wrote:

> Bonjour a tous,
>
> What do you think about setting a new primitive datatype "Password"  
> in addition to "String", "Integer", "DateTime", "Float", "Boolean"?
>
> We plan to use secondary inputs to control some web-services access  
> (using login/password).
> Defining such a primitive datatype for parameters could be usefull  
> for web interface: we could deal with this kind of parameters as we  
> do with password fields in HTML forms.
>
> What is your point of view ?
>
> Merci,
>
> Sebastien
> <Sebastien_Carrere.vcf>_______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone: +31 (0)6-143 66 783
email: pieter.neerincx at gmail.com
skype: pieter.online
------------------------------------------------------------



From dmitry.repchevski at bsc.es  Tue Mar 24 17:48:17 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 14:48:17 -0700
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C8D4F5.10104@uma.es>
References: <49C8D4F5.10104@uma.es>
Message-ID: <49C95521.10300@bsc.es>

Hello Sergio!

I use wsdl4j. It just fine for me.
Do you have any specific question?

Dmitry

From Sebastien.Carrere at toulouse.inra.fr  Tue Mar 24 10:27:31 2009
From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Tue, 24 Mar 2009 15:27:31 +0100
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <203FDC18-6B4B-46D5-8CB2-493D769F576A@gmail.com>
References: <49C8A77C.1010104@toulouse.inra.fr>
	<203FDC18-6B4B-46D5-8CB2-493D769F576A@gmail.com>
Message-ID: <49C8EDD3.1070208@toulouse.inra.fr>

Hi Pieter,


> 1. There is already a password datatype in the object ontology that 
> you can use... It's not a primitive, but I don't see why it would have 
> to be. It currently simply inherits from Object. Hence Password ISA 
> Object. (There has been some discussion on wether or not to create 
> more specialised objects without adding any children, but Password has 
> been around for several years now...)
Yes, I've seen this existing object, but it can not be used as a 
Secondary input type (because secondary only accept primitive as far as 
I know)
>
> 2. Secondaries are something different than Primitives. The Primitives 
> are always (part of) primary inputs or outputs and the primitives are 
> therefore part of the object ontology. Note that secondary inputs or 
> outputs are not part of the object ontology. The secondaries do come 
> in exactly the same flavors as the primitives: "String", "Integer", 
> "DateTime", "Float", "Boolean". So I can understand the confusion...
>
> Hence with what is currently available you can already use:
> * A Password object as primary input.
> * A String primitive with the articleName attribute password or 
> something similar.
> * A secondary input of type String with the articleName attribute 
> password or something similar.
This last point is exactly what I plan to do, but we have to use the 
same articleName (password is a good one) to be able to identify such 
particular parameters.

>
> There are several services that use similar constructs. They all work 
> just fine. The only problem is that there is no standardised mechanism 
> for authentication in BioMoby, which is not so user friendly.... A 
> standardised mechanism would be nice and having a password and 
> optional login/accountname as primaries or secondaries makes sense to 
> me. All we would have to do is agree on the object (for primaries) or 
> type (for secondaries) and articleName for these.... Theoretically a 
> secondary input is optional and a client should be able to leave it 
> out. Most secured services will require a password though, so one can 
> argue that passwords and logins must be primary inputs. I don't think 
> it matters too much. As long as we standardise on something it would 
> make it easier for clients to figure out how to do authentication.
>
> There are several people who will probably suggest to handle logins 
> and password on a different level. You can do it on the transport 
> level, on the web server level, in the SOAP layer or you could use 
> WSRF et al. Some of these would be theoretically more elegant, but 
> they usually cause more overhead and more time to implement. Doing it 
> in BioMoby ourselves is peanuts and gives us more control on how to do 
> it: no external dependancies, libraries, etc. So I think handling 
> authentication in BioMoby is the more pragmatic solution. My services 
> use the Password object for several years now: it was easy to 
> implement and works just fine :)
I totally agree with your point of view, becasue in our case, 
web-services are just wrapped programs that we use also as cli and as 
Mobyle services. That's why we have to deal authentication directly at 
the web-service/script level and not at the transport level.
And as you say, using secondary inputs seems the best way to allow 
public-users (non authetified ones) to access limited web-services and 
registered-users to access full ones.

So I'm going to use Secondary inputs of type String with the articleName 
attribute password.


Sebastien




>> Bonjour a tous,
>>
>> What do you think about setting a new primitive datatype "Password" 
>> in addition to "String", "Integer", "DateTime", "Float", "Boolean"?
>>
>> We plan to use secondary inputs to control some web-services access 
>> (using login/password).
>> Defining such a primitive datatype for parameters could be usefull 
>> for web interface: we could deal with this kind of parameters as we 
>> do with password fields in HTML forms.
>>
>> What is your point of view ?
>>
>> Merci,
>>
>> Sebastien
>> <Sebastien_Carrere.vcf>_______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone: +31 (0)6-143 66 783
> email: pieter.neerincx at gmail.com
> skype: pieter.online
> ------------------------------------------------------------
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sebastien_Carrere.vcf
Type: text/x-vcard
Size: 387 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090324/3520afce/attachment.vcf>

From srramirez at uma.es  Tue Mar 24 10:31:29 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Mar 2009 15:31:29 +0100
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C95521.10300@bsc.es>
References: <49C8D4F5.10104@uma.es> <49C95521.10300@bsc.es>
Message-ID: <49C8EEC1.8050707@uma.es>

Thanks for  the answer Dmitry.

With wsdl4j my problem was that I couldn't access the datatypes of 
service parameters, it always return me null.

Dmitry Repchevsky wrote:
> Hello Sergio!
>
> I use wsdl4j. It just fine for me.
> Do you have any specific question?
>
> Dmitry
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>


-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 


From dmitry.repchevski at bsc.es  Tue Mar 24 18:49:11 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 15:49:11 -0700
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C8EEC1.8050707@uma.es>
References: <49C8EEC1.8050707@uma.es>
Message-ID: <49C96367.7070300@bsc.es>

I an not sure about RPC-encoded...

WSDLParser parser
List<QName> paramz  = parser.getInputParameters(service, port, 
operation); // service, port, operation are QName

The problem is that after getting the name (in "document" type) you have 
to parss XML Schema...

I started an utility to execute any WSDL service (something Taverna 
fails to do). The idea is the same - given WSDL obtain services, schemas 
and be able to EDIT an input to it...
Unfortunately I had to switch to another project and have no workable 
code now... But sure I will finish it one day :-)
I need it to be able to execute my Nemus services:
http://inb.bsc.es/documents/java/nemus/index.html

Cheers,

Dmitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WSDLExecutor.png
Type: image/png
Size: 25832 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090324/35ba3a01/attachment-0001.png>

From srramirez at uma.es  Tue Mar 24 11:06:25 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Mar 2009 16:06:25 +0100
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C96367.7070300@bsc.es>
References: <49C8EEC1.8050707@uma.es> <49C96367.7070300@bsc.es>
Message-ID: <49C8F6F1.1030400@uma.es>

Dear Dmitry

Thank you very much for your help, I think maybe we can share 
experiences. Moving to wsif I can parse the datatypes of an wsdl 
document. Is very nice you can check the if it is an array or not, the 
component  elements and other things.

It works for me for a set of wsdl files, but when I switch to another 
set simply it doesn't give me any attribute.

So that is my problem.

Dmitry Repchevsky wrote:
> I an not sure about RPC-encoded...
>
> WSDLParser parser
> List<QName> paramz  = parser.getInputParameters(service, port, 
> operation); // service, port, operation are QName
>
> The problem is that after getting the name (in "document" type) you 
> have to parss XML Schema...
>
> I started an utility to execute any WSDL service (something Taverna 
> fails to do). The idea is the same - given WSDL obtain services, 
> schemas and be able to EDIT an input to it...
> Unfortunately I had to switch to another project and have no workable 
> code now... But sure I will finish it one day :-)
> I need it to be able to execute my Nemus services:
> http://inb.bsc.es/documents/java/nemus/index.html
>
> Cheers,
>
> Dmitry
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>   


-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 


From soiland-reyes at cs.manchester.ac.uk  Tue Mar 24 12:20:52 2009
From: soiland-reyes at cs.manchester.ac.uk (Stian Soiland-Reyes)
Date: Tue, 24 Mar 2009 16:20:52 +0000
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C96367.7070300@bsc.es>
References: <49C8EEC1.8050707@uma.es> <49C96367.7070300@bsc.es>
Message-ID: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>

2009/3/24 Dmitry Repchevsky <dmitry.repchevski at bsc.es>:

> I started an utility to execute any WSDL service (something Taverna fails to
> do). The idea is the same - given WSDL obtain services, schemas and be able

Hi!

It would be great if you could report to the taverna-hackers list [1]
any WSDL Taverna fails to understand or invoke. We have as a goal that
Taverna should be able to invoke any WSDL-service.

If the service in question is not publicly available, you could try to
attach the WSDL and any schema files (and example workflows that
fails) to your message.


[1] http://www.mygrid.org.uk/tools/taverna/taverna-mailing-lists/



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

From dmitry.repchevski at bsc.es  Tue Mar 24 20:47:13 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 17:47:13 -0700
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>
References: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>
Message-ID: <49C97F11.3010102@bsc.es>

Hello Stian!

I read in taverna mailing list that it has problems with "bare" services 
(and it was so few months ago, I checked). Also it has problem with 
complex schema (inheritance).

Try
http://inb.bsc.es/gn6/proxy/runPhylipKitsch?wsdl

I developed a proxy to all our Moby services representing them as WSDL + 
Schema

I would be happy to be able to use them in a workflow.
Also I think the way Taverna parses XML input/output (splitters) is far 
away from the best one...

Dmitry

From soiland-reyes at cs.manchester.ac.uk  Wed Mar 25 04:23:08 2009
From: soiland-reyes at cs.manchester.ac.uk (Stian Soiland-Reyes)
Date: Wed, 25 Mar 2009 08:23:08 +0000
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C97F11.3010102@bsc.es>
References: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>
	<49C97F11.3010102@bsc.es>
Message-ID: <a20e6fb10903250123t6bfd2f8cs4b8153242c0c719c@mail.gmail.com>

On Wed, Mar 25, 2009 at 00:47, Dmitry Repchevsky
<dmitry.repchevski at bsc.es> wrote:
> Hello Stian!
>
> I read in taverna mailing list that it has problems with "bare" services
> (and it was so few months ago, I checked). Also it has problem with complex
> schema (inheritance).

I haven't heard about this "bare" problem.. I can't see it in on our
mailing list archives or bug tracker..


> Try
> http://inb.bsc.es/gn6/proxy/runPhylipKitsch?wsdl

What would be an example input and output for that service..?


I agree that for some quite complex types you do get a lot of XML
splitters - this comes down to XML splitters working on the level of
one per element/type.

That's something we want to improve by hiding the splitters and doing
instead some kind of port selection based on the schema, from within a
configuration dialogue of the WSDL activity. [1]

http://www.mygrid.org.uk/dev/issues/browse/TAV-510


If you're on the taverna-hackers, let's continue the thread there! :-)

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

From edward.kawas at gmail.com  Wed Mar 25 13:29:44 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 25 Mar 2009 10:29:44 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B7F2BF.2060801@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
Message-ID: <49ca6a0a.02578c0a.295c.13de@mx.google.com>

Based on what Paul has said, is it true that the datatypes
(GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?

Thanks,

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: March-11-09 10:20 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

I can confirm that member articleNames must be unique.  Otherwise there 
would be no way to distinguish two HAS and a HAS-A instance.

Edward Kawas wrote:
> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't
find
> any documentation online saying that articlenames describing relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
>  
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout 
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are 
> only registered at Central registry, so they are fetched when Biomoby 
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>   
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating
these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
>>     
> corresponding
>   
>> ant tasks, but after fetching all necessary libraries, the compilation
>>     
> fails
>   
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
>>     
> one
>   
>> of my services with an existing Biomoby instance on another machine.
There
>> the build also fails. 
>> I tested this on 3 different machines, including both Ubuntu and XP os.
>>     
> The
>   
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>>     
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>   
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>     
> override
>   
>> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>   
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>   
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_foreign_transposable_element.java:112:
getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>     
> override
>   
>> getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>   
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                                             ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                            
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>   
>>     
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From pieter.neerincx at gmail.com  Wed Mar 25 19:45:09 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Thu, 26 Mar 2009 00:45:09 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49ca6a0a.02578c0a.295c.13de@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
	<49ca6a0a.02578c0a.295c.13de@mx.google.com>
Message-ID: <6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>

Hi,

If I remember correctly for datatypes it's the combination of the  
object's name and articleName attribute value that must be unique. As  
long as the combi is unique you can distinguish two HAS and a HAS-A  
instance. Therefore if an object has multiple relationships involving  
child element of the same type a unique articleName attribute is  
mandatory but otherwise articleName attributes were optional. In  
addition articleNames in service inputs or outputs were mandatory and  
quite some time ago articleNames became also mandatory for primitives  
no matter whether there was only one relationship involving a certain  
type of primitive or whether there were more.

So AFAIK the GCP_* objects mentioned below are correctly registered  
according to the current specs, but to keep things simple it wouldn't  
hurt to make articleName attributes always mandatory. That would  
render quite some currently used objects invalid though...

Cheers,

Pi

On 25 Mar 2009, at 18:29, Edward Kawas wrote:

> Based on what Paul has said, is it true that the datatypes
> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>
> Thanks,
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: March-11-09 10:20 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> I can confirm that member articleNames must be unique.  Otherwise  
> there
> would be no way to distinguish two HAS and a HAS-A instance.
>
> Edward Kawas wrote:
>> I think that I may have figured it out.
>>
>> Using the datatype SOTest2_validated_cDNA_clone as an example, I  
>> think
> that
>> the main problem is that the datatype has 2 has relationships. It has
>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that  
>> they
> both
>> have the articlename 'has_quality'.
>>
>> I am sure that articlenames in Services have to be unique, but I  
>> can't
> find
>> any documentation online saying that articlenames describing  
>> relationships
>> in Datatypes have to be unique as well.
>>
>> So, if articlenames have to be unique, then the registry  
>> inadvertently
>> allowed the registration of datatypes without unique articlenames for
>> container relationships. Alternatively, if this is allowed, then a  
>> bug was
>> discovered in MoSeS.
>>
>> Anyone have any insight into which one is the correct scenario?
>>
>> Eddie
>>
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-11-09 4:14 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi Eddie,
>>
>> I'am using Suns JDK 1.5 Version 16. I also encountered this  
>> behavivour
>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>> generated services and axis 1.4 and Tomcat5.5).
>>
>> This problem also occurs when I run install from a fresh CVS checkout
>> (including a fresh Biomoby cache directory). All SOTEST* datatypes  
>> are
>> only registered at Central registry, so they are fetched when Biomoby
>> fills its cache (retrieving datatypes).
>>
>> Regards,
>>
>> Michael
>>
>>
>>> Hi Michael,
>>>
>>> What version of JAVA are you using? What registry are you generating
> these
>>> datatypes from?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>>> Gerlich
>>> Sent: March-10-09 4:28 PM
>>> To: MOBY-dev at lists.open-bio.org
>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi all,
>>>
>>> I checked out Biomoby from CVS and tried to install it via the
>>>
>> corresponding
>>
>>> ant tasks, but after fetching all necessary libraries, the  
>>> compilation
>>>
>> fails
>>
>>> with a lot of error messages regarding datatypes SOTEST*.
>>>
>>> I also encountered this behavior when I tried to run Moses  
>>> Generator for
>>>
>> one
>>
>>> of my services with an existing Biomoby instance on another machine.
> There
>>> the build also fails.
>>> I tested this on 3 different machines, including both Ubuntu and  
>>> XP os.
>>>
>> The
>>
>>> error log is attached, taken from Dashboad.
>>>
>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>
>>> Thanks in advance and regards,
>>> Michael
>>>
>>>
>>> Excerpt follows (100 error messages like this):
>>>
>>>
>>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/datat
>>
>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>
>> override
>>
>>> getMoby_Parent() in  
>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>> attempting to use incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>    [javac] required:
>>>
>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>
>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>> getMoby_has_quality() in
>>>
>>>
>>
> org 
> .biomoby 
> .shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>
>>> cannot override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>> attempting
> to
>>> use incompatible return type
>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>    [javac]                              ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_foreign_transposable_element.java:112:
> getMoby_has_quality()
>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>
>> cannot
>>
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>> attempting
> to
>>> use incompatible return type
>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>    [javac]                              ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_fusion_gene.java:122:  
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>
>> override
>>
>>> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>> attempting to use incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_rescue_region.java:120:  
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to  
>>> use
>>> incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_transposable_element.java:121:
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>
>> cannot
>>
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>> attempting
> to
>>> use incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>> getMoby_part_of() in
>>>
>>>
>>
> org 
> .biomoby 
> .shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>
>>> cannot override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting  
>>> to use
>>> incompatible return type
>>>    [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>    [javac] required:  
>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>    [javac]     public SOTest2_five_prime_coding_exon[]  
>>> getMoby_part_of()
>>>
>> {
>>
>>>    [javac]                                             ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_five_prime_exon_coding_region.java:114:  
>>> getMoby_part_of()
> in
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>>> cannot
>>> override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting  
>>> to use
>>> incompatible return type
>>>    [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>    [javac] required:  
>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>    [javac]     public SOTest2_five_prime_coding_exon[]  
>>> getMoby_part_of()
>>>
>> {
>>
>>>    [javac]
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------




From gordonp at ucalgary.ca  Thu Mar 26 10:31:02 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu, 26 Mar 2009 08:31:02 -0600
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>
	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>
Message-ID: <49CB91A6.4030601@ucalgary.ca>

As there is no unique place to put documentation for the purpose or 
usage of a member other than its articleName, I'd suggest that the 
articleName be mandatory, if only for the purpose of succinctly 
describing the relationship between it and the container class.

Pieter Neerincx wrote:
> Hi,
>
> If I remember correctly for datatypes it's the combination of the 
> object's name and articleName attribute value that must be unique. As 
> long as the combi is unique you can distinguish two HAS and a HAS-A 
> instance. Therefore if an object has multiple relationships involving 
> child element of the same type a unique articleName attribute is 
> mandatory but otherwise articleName attributes were optional. In 
> addition articleNames in service inputs or outputs were mandatory and 
> quite some time ago articleNames became also mandatory for primitives 
> no matter whether there was only one relationship involving a certain 
> type of primitive or whether there were more.
>
> So AFAIK the GCP_* objects mentioned below are correctly registered 
> according to the current specs, but to keep things simple it wouldn't 
> hurt to make articleName attributes always mandatory. That would 
> render quite some currently used objects invalid though...
>
> Cheers,
>
> Pi
>
> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>
>> Based on what Paul has said, is it true that the datatypes
>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: March-11-09 10:20 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> I can confirm that member articleNames must be unique.  Otherwise there
>> would be no way to distinguish two HAS and a HAS-A instance.
>>
>> Edward Kawas wrote:
>>> I think that I may have figured it out.
>>>
>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>>> the main problem is that the datatype has 2 has relationships. It has
>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>>> have the articlename 'has_quality'.
>>>
>>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>>> any documentation online saying that articlenames describing 
>>> relationships
>>> in Datatypes have to be unique as well.
>>>
>>> So, if articlenames have to be unique, then the registry inadvertently
>>> allowed the registration of datatypes without unique articlenames for
>>> container relationships. Alternatively, if this is allowed, then a 
>>> bug was
>>> discovered in MoSeS.
>>>
>>> Anyone have any insight into which one is the correct scenario?
>>>
>>> Eddie
>>>
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>> Gerlich
>>> Sent: March-11-09 4:14 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi Eddie,
>>>
>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>> generated services and axis 1.4 and Tomcat5.5).
>>>
>>> This problem also occurs when I run install from a fresh CVS checkout
>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>> only registered at Central registry, so they are fetched when Biomoby
>>> fills its cache (retrieving datatypes).
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> What version of JAVA are you using? What registry are you generating
>> these
>>>> datatypes from?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>> Gerlich
>>>> Sent: March-10-09 4:28 PM
>>>> To: MOBY-dev at lists.open-bio.org
>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi all,
>>>>
>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>
>>> corresponding
>>>
>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>
>>> fails
>>>
>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>
>>>> I also encountered this behavior when I tried to run Moses 
>>>> Generator for
>>>>
>>> one
>>>
>>>> of my services with an existing Biomoby instance on another machine.
>> There
>>>> the build also fails.
>>>> I tested this on 3 different machines, including both Ubuntu and XP 
>>>> os.
>>>>
>>> The
>>>
>>>> error log is attached, taken from Dashboad.
>>>>
>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>
>>>> Thanks in advance and regards,
>>>> Michael
>>>>
>>>>
>>>> Excerpt follows (100 error messages like this):
>>>>
>>>>
>>>>
>>>
>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat 
>>
>>>
>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_Parent() in 
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>    [javac] required:
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>
>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>>
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element 
>>
>>>
>>>> cannot override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_foreign_transposable_element.java:112:
>> getMoby_has_quality()
>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>> incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>> getMoby_part_of() in
>>>>
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region 
>>
>>>
>>>> cannot override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]                                             ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>> getMoby_part_of()
>> in
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region 
>>>> cannot
>>>> override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone:  +31 (0)317-483 060
> mobile: +31 (0)6-143 66 783
> e-mail: pieter.neerincx at gmail.com
> skype:  pieter.online
> -------------------------------------------------------------
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>

From edward.kawas at gmail.com  Thu Mar 26 11:00:41 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 26 Mar 2009 08:00:41 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49CB91A6.4030601@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>
	<49CB91A6.4030601@ucalgary.ca>
Message-ID: <49cb989d.15528c0a.1739.69c0@mx.google.com>

I thought that the articlename was supposed to be mandatory... anyways, the
2 services that I mentioned seem to be the only 2 incorrect datatypes. I
created a patch for the registry, but before I committed it, I wanted to
check that I had the general idea down.

The patch works like so:

User X is registering a datatype. We take all of the direct HAS/HASA
articlenames and then traverse the ISA hierarchy towards the root node
ensuring that the articlenames are not used further up the tree.

This is how I found those 2 datatypes that I mentioned previously. I tested
my patch against all datatypes in our ontology.

If everyone is happy with this, I will commit the patch and update the
documentation.

Thanks,

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: March-26-09 7:31 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

As there is no unique place to put documentation for the purpose or 
usage of a member other than its articleName, I'd suggest that the 
articleName be mandatory, if only for the purpose of succinctly 
describing the relationship between it and the container class.

Pieter Neerincx wrote:
> Hi,
>
> If I remember correctly for datatypes it's the combination of the 
> object's name and articleName attribute value that must be unique. As 
> long as the combi is unique you can distinguish two HAS and a HAS-A 
> instance. Therefore if an object has multiple relationships involving 
> child element of the same type a unique articleName attribute is 
> mandatory but otherwise articleName attributes were optional. In 
> addition articleNames in service inputs or outputs were mandatory and 
> quite some time ago articleNames became also mandatory for primitives 
> no matter whether there was only one relationship involving a certain 
> type of primitive or whether there were more.
>
> So AFAIK the GCP_* objects mentioned below are correctly registered 
> according to the current specs, but to keep things simple it wouldn't 
> hurt to make articleName attributes always mandatory. That would 
> render quite some currently used objects invalid though...
>
> Cheers,
>
> Pi
>
> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>
>> Based on what Paul has said, is it true that the datatypes
>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: March-11-09 10:20 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> I can confirm that member articleNames must be unique.  Otherwise there
>> would be no way to distinguish two HAS and a HAS-A instance.
>>
>> Edward Kawas wrote:
>>> I think that I may have figured it out.
>>>
>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>>> the main problem is that the datatype has 2 has relationships. It has
>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>>> have the articlename 'has_quality'.
>>>
>>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>>> any documentation online saying that articlenames describing 
>>> relationships
>>> in Datatypes have to be unique as well.
>>>
>>> So, if articlenames have to be unique, then the registry inadvertently
>>> allowed the registration of datatypes without unique articlenames for
>>> container relationships. Alternatively, if this is allowed, then a 
>>> bug was
>>> discovered in MoSeS.
>>>
>>> Anyone have any insight into which one is the correct scenario?
>>>
>>> Eddie
>>>
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>> Gerlich
>>> Sent: March-11-09 4:14 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi Eddie,
>>>
>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>> generated services and axis 1.4 and Tomcat5.5).
>>>
>>> This problem also occurs when I run install from a fresh CVS checkout
>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>> only registered at Central registry, so they are fetched when Biomoby
>>> fills its cache (retrieving datatypes).
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> What version of JAVA are you using? What registry are you generating
>> these
>>>> datatypes from?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>> Gerlich
>>>> Sent: March-10-09 4:28 PM
>>>> To: MOBY-dev at lists.open-bio.org
>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi all,
>>>>
>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>
>>> corresponding
>>>
>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>
>>> fails
>>>
>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>
>>>> I also encountered this behavior when I tried to run Moses 
>>>> Generator for
>>>>
>>> one
>>>
>>>> of my services with an existing Biomoby instance on another machine.
>> There
>>>> the build also fails.
>>>> I tested this on 3 different machines, including both Ubuntu and XP 
>>>> os.
>>>>
>>> The
>>>
>>>> error log is attached, taken from Dashboad.
>>>>
>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>
>>>> Thanks in advance and regards,
>>>> Michael
>>>>
>>>>
>>>> Excerpt follows (100 error messages like this):
>>>>
>>>>
>>>>
>>>
>>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat

>>
>>>
>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_Parent() in 
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>    [javac] required:
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>
>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>>
>>>>
>>>
>>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element

>>
>>>
>>>> cannot override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_foreign_transposable_element.java:112:
>> getMoby_has_quality()
>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>> incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>> getMoby_part_of() in
>>>>
>>>>
>>>
>>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region

>>
>>>
>>>> cannot override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]                                             ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>> getMoby_part_of()
>> in
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region 
>>>> cannot
>>>> override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone:  +31 (0)317-483 060
> mobile: +31 (0)6-143 66 783
> e-mail: pieter.neerincx at gmail.com
> skype:  pieter.online
> -------------------------------------------------------------
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From gordonp at ucalgary.ca  Thu Mar 26 11:07:09 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu, 26 Mar 2009 09:07:09 -0600
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49cb989d.15528c0a.1739.69c0@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>	<49CB91A6.4030601@ucalgary.ca>
	<49cb989d.15528c0a.1739.69c0@mx.google.com>
Message-ID: <49CB9A1D.7040404@ucalgary.ca>

Sounds good to me.  If the docs don't say articleName is mandatory, that 
was an error of omission on our part...

Edward Kawas wrote:
> I thought that the articlename was supposed to be mandatory... anyways, the
> 2 services that I mentioned seem to be the only 2 incorrect datatypes. I
> created a patch for the registry, but before I committed it, I wanted to
> check that I had the general idea down.
>
> The patch works like so:
>
> User X is registering a datatype. We take all of the direct HAS/HASA
> articlenames and then traverse the ISA hierarchy towards the root node
> ensuring that the articlenames are not used further up the tree.
>
> This is how I found those 2 datatypes that I mentioned previously. I tested
> my patch against all datatypes in our ontology.
>
> If everyone is happy with this, I will commit the patch and update the
> documentation.
>
> Thanks,
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: March-26-09 7:31 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> As there is no unique place to put documentation for the purpose or 
> usage of a member other than its articleName, I'd suggest that the 
> articleName be mandatory, if only for the purpose of succinctly 
> describing the relationship between it and the container class.
>
> Pieter Neerincx wrote:
>   
>> Hi,
>>
>> If I remember correctly for datatypes it's the combination of the 
>> object's name and articleName attribute value that must be unique. As 
>> long as the combi is unique you can distinguish two HAS and a HAS-A 
>> instance. Therefore if an object has multiple relationships involving 
>> child element of the same type a unique articleName attribute is 
>> mandatory but otherwise articleName attributes were optional. In 
>> addition articleNames in service inputs or outputs were mandatory and 
>> quite some time ago articleNames became also mandatory for primitives 
>> no matter whether there was only one relationship involving a certain 
>> type of primitive or whether there were more.
>>
>> So AFAIK the GCP_* objects mentioned below are correctly registered 
>> according to the current specs, but to keep things simple it wouldn't 
>> hurt to make articleName attributes always mandatory. That would 
>> render quite some currently used objects invalid though...
>>
>> Cheers,
>>
>> Pi
>>
>> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>>
>>     
>>> Based on what Paul has said, is it true that the datatypes
>>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: March-11-09 10:20 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> I can confirm that member articleNames must be unique.  Otherwise there
>>> would be no way to distinguish two HAS and a HAS-A instance.
>>>
>>> Edward Kawas wrote:
>>>       
>>>> I think that I may have figured it out.
>>>>
>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>>>         
>>> that
>>>       
>>>> the main problem is that the datatype has 2 has relationships. It has
>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>>>         
>>> both
>>>       
>>>> have the articlename 'has_quality'.
>>>>
>>>> I am sure that articlenames in Services have to be unique, but I can't
>>>>         
>>> find
>>>       
>>>> any documentation online saying that articlenames describing 
>>>> relationships
>>>> in Datatypes have to be unique as well.
>>>>
>>>> So, if articlenames have to be unique, then the registry inadvertently
>>>> allowed the registration of datatypes without unique articlenames for
>>>> container relationships. Alternatively, if this is allowed, then a 
>>>> bug was
>>>> discovered in MoSeS.
>>>>
>>>> Anyone have any insight into which one is the correct scenario?
>>>>
>>>> Eddie
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>> Gerlich
>>>> Sent: March-11-09 4:14 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi Eddie,
>>>>
>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>
>>>> This problem also occurs when I run install from a fresh CVS checkout
>>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>>> only registered at Central registry, so they are fetched when Biomoby
>>>> fills its cache (retrieving datatypes).
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>>         
>>>>> Hi Michael,
>>>>>
>>>>> What version of JAVA are you using? What registry are you generating
>>>>>           
>>> these
>>>       
>>>>> datatypes from?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eddie
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>>> Gerlich
>>>>> Sent: March-10-09 4:28 PM
>>>>> To: MOBY-dev at lists.open-bio.org
>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>>
>>>>>           
>>>> corresponding
>>>>
>>>>         
>>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>>
>>>>>           
>>>> fails
>>>>
>>>>         
>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>
>>>>> I also encountered this behavior when I tried to run Moses 
>>>>> Generator for
>>>>>
>>>>>           
>>>> one
>>>>
>>>>         
>>>>> of my services with an existing Biomoby instance on another machine.
>>>>>           
>>> There
>>>       
>>>>> the build also fails.
>>>>> I tested this on 3 different machines, including both Ubuntu and XP 
>>>>> os.
>>>>>
>>>>>           
>>>> The
>>>>
>>>>         
>>>>> error log is attached, taken from Dashboad.
>>>>>
>>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>
>>>>> Thanks in advance and regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Excerpt follows (100 error messages like this):
>>>>>
>>>>>
>>>>>
>>>>>           
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>
>   
>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>>
>>>>>           
>>>> override
>>>>
>>>>         
>>>>> getMoby_Parent() in 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>    [javac] required:
>>>>>
>>>>>           
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>
>>>>         
>>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>>
>>>>>
>>>>>           
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>
>   
>>>>> cannot override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>>           
>>> to
>>>       
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>>           
>>> getMoby_has_quality()
>>>       
>>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>>
>>>>>           
>>>> cannot
>>>>
>>>>         
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>>           
>>> to
>>>       
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>>
>>>>>           
>>>> override
>>>>
>>>>         
>>>>> getMoby_has_quality() in
>>>>>           
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>       
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>>> incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>>
>>>>>           
>>>> cannot
>>>>
>>>>         
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>>           
>>> to
>>>       
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>> getMoby_part_of() in
>>>>>
>>>>>
>>>>>           
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>
>   
>>>>> cannot override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>>> getMoby_part_of()
>>>>>
>>>>>           
>>>> {
>>>>
>>>>         
>>>>>    [javac]                                             ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>>> getMoby_part_of()
>>>>>           
>>> in
>>>       
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region 
>>>>> cannot
>>>>> override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>>> getMoby_part_of()
>>>>>
>>>>>           
>>>> {
>>>>
>>>>         
>>>>>    [javac]
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>       
>> -------------------------------------------------------------
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>>
>> phone:  +31 (0)317-483 060
>> mobile: +31 (0)6-143 66 783
>> e-mail: pieter.neerincx at gmail.com
>> skype:  pieter.online
>> -------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   

From markw at illuminae.com  Thu Mar 26 11:25:33 2009
From: markw at illuminae.com (markw at illuminae.com)
Date: Thu, 26 Mar 2009 15:25:33 +0000
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49CB9A1D.7040404@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>	<49CB91A6.4030601@ucalgary.ca><49cb989d.15528c0a.1739.69c0@mx.google.com><49CB9A1D.7040404@ucalgary.ca>
Message-ID: <691129944-1238081155-cardhu_decombobulator_blackberry.rim.net-1674883723-@bxe1187.bisx.prod.on.blackberry>

Agree 100% - I'm surprised that it isn't in the docs (if it isn't... It certainly *used* to be, but the docs have been moved around and edited quite a bit over the years)

M


On the Road!

-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>

Date: Thu, 26 Mar 2009 09:07:09 
To: Core developer announcements<moby-dev at lists.open-bio.org>
Subject: Re: [MOBY-dev] error installing Biomoby via ant


Sounds good to me.  If the docs don't say articleName is mandatory, that
was an error of omission on our part...

Edward Kawas wrote:
> I thought that the articlename was supposed to be mandatory... anyways, the
> 2 services that I mentioned seem to be the only 2 incorrect datatypes. I
> created a patch for the registry, but before I committed it, I wanted to
> check that I had the general idea down.
>
> The patch works like so:
>
> User X is registering a datatype. We take all of the direct HAS/HASA
> articlenames and then traverse the ISA hierarchy towards the root node
> ensuring that the articlenames are not used further up the tree.
>
> This is how I found those 2 datatypes that I mentioned previously. I tested
> my patch against all datatypes in our ontology.
>
> If everyone is happy with this, I will commit the patch and update the
> documentation.
>
> Thanks,
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: March-26-09 7:31 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> As there is no unique place to put documentation for the purpose or
> usage of a member other than its articleName, I'd suggest that the
> articleName be mandatory, if only for the purpose of succinctly
> describing the relationship between it and the container class.
>
> Pieter Neerincx wrote:
>
>> Hi,
>>
>> If I remember correctly for datatypes it's the combination of the
>> object's name and articleName attribute value that must be unique. As
>> long as the combi is unique you can distinguish two HAS and a HAS-A
>> instance. Therefore if an object has multiple relationships involving
>> child element of the same type a unique articleName attribute is
>> mandatory but otherwise articleName attributes were optional. In
>> addition articleNames in service inputs or outputs were mandatory and
>> quite some time ago articleNames became also mandatory for primitives
>> no matter whether there was only one relationship involving a certain
>> type of primitive or whether there were more.
>>
>> So AFAIK the GCP_* objects mentioned below are correctly registered
>> according to the current specs, but to keep things simple it wouldn't
>> hurt to make articleName attributes always mandatory. That would
>> render quite some currently used objects invalid though...
>>
>> Cheers,
>>
>> Pi
>>
>> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>>
>>
>>> Based on what Paul has said, is it true that the datatypes
>>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: March-11-09 10:20 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> I can confirm that member articleNames must be unique.  Otherwise there
>>> would be no way to distinguish two HAS and a HAS-A instance.
>>>
>>> Edward Kawas wrote:
>>>
>>>> I think that I may have figured it out.
>>>>
>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>>>
>>> that
>>>
>>>> the main problem is that the datatype has 2 has relationships. It has
>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>>>
>>> both
>>>
>>>> have the articlename 'has_quality'.
>>>>
>>>> I am sure that articlenames in Services have to be unique, but I can't
>>>>
>>> find
>>>
>>>> any documentation online saying that articlenames describing
>>>> relationships
>>>> in Datatypes have to be unique as well.
>>>>
>>>> So, if articlenames have to be unique, then the registry inadvertently
>>>> allowed the registration of datatypes without unique articlenames for
>>>> container relationships. Alternatively, if this is allowed, then a
>>>> bug was
>>>> discovered in MoSeS.
>>>>
>>>> Anyone have any insight into which one is the correct scenario?
>>>>
>>>> Eddie
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>> Gerlich
>>>> Sent: March-11-09 4:14 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi Eddie,
>>>>
>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>
>>>> This problem also occurs when I run install from a fresh CVS checkout
>>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>>> only registered at Central registry, so they are fetched when Biomoby
>>>> fills its cache (retrieving datatypes).
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> What version of JAVA are you using? What registry are you generating
>>>>>
>>> these
>>>
>>>>> datatypes from?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eddie
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>>> Gerlich
>>>>> Sent: March-10-09 4:28 PM
>>>>> To: MOBY-dev at lists.open-bio.org
>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>>
>>>>>
>>>> corresponding
>>>>
>>>>
>>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>>
>>>>>
>>>> fails
>>>>
>>>>
>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>
>>>>> I also encountered this behavior when I tried to run Moses
>>>>> Generator for
>>>>>
>>>>>
>>>> one
>>>>
>>>>
>>>>> of my services with an existing Biomoby instance on another machine.
>>>>>
>>> There
>>>
>>>>> the build also fails.
>>>>> I tested this on 3 different machines, including both Ubuntu and XP
>>>>> os.
>>>>>
>>>>>
>>>> The
>>>>
>>>>
>>>>> error log is attached, taken from Dashboad.
>>>>>
>>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>
>>>>> Thanks in advance and regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Excerpt follows (100 error messages like this):
>>>>>
>>>>>
>>>>>
>>>>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>
>
>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>>
>>>>>
>>>> override
>>>>
>>>>
>>>>> getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>    [javac] required:
>>>>>
>>>>>
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>
>>>>
>>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>>
>>>>>
>>>>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>
>
>>>>> cannot override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;
>>>>> attempting
>>>>>
>>> to
>>>
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>>
>>> getMoby_has_quality()
>>>
>>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;
>>>>> attempting
>>>>>
>>> to
>>>
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_fusion_gene.java:122:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>>
>>>>>
>>>> override
>>>>
>>>>
>>>>> getMoby_has_quality() in
>>>>>
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_rescue_region.java:120:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>>> incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;
>>>>> attempting
>>>>>
>>> to
>>>
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>> getMoby_part_of() in
>>>>>
>>>>>
>>>>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>
>
>>>>> cannot override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>>>
>>>>>
>>>> {
>>>>
>>>>
>>>>>    [javac]                                             ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_five_prime_exon_coding_region.java:114:
>>>>> getMoby_part_of()
>>>>>
>>> in
>>>
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>>>> cannot
>>>>> override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>>>
>>>>>
>>>> {
>>>>
>>>>
>>>>>    [javac]
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>> -------------------------------------------------------------
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>>
>> phone:  +31 (0)317-483 060
>> mobile: +31 (0)6-143 66 783
>> e-mail: pieter.neerincx at gmail.com
>> skype:  pieter.online
>> -------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From pieter.neerincx at gmail.com  Thu Mar 26 11:47:31 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Thu, 26 Mar 2009 16:47:31 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49CB9A1D.7040404@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>	<49CB91A6.4030601@ucalgary.ca>
	<49cb989d.15528c0a.1739.69c0@mx.google.com>
	<49CB9A1D.7040404@ucalgary.ca>
Message-ID: <B9532ED4-462E-47EB-8FEF-A08DABEDAB0B@gmail.com>

Making the articleName attributes mandatory in all cases will also  
help to make MoSeS generated code more readable. If the optional  
articleName attributes are missing, MoSeS will generate some variables  
with "placeholder names". If you have more than one of those, things  
can get rather confusing. So you have my vote for making articleName  
attributes mandatory in all circumstances!

Cheers,

Pi

On 26 Mar 2009, at 16:07, Paul Gordon wrote:

> Sounds good to me.  If the docs don't say articleName is mandatory,  
> that was an error of omission on our part...
>
> Edward Kawas wrote:
>> I thought that the articlename was supposed to be mandatory...  
>> anyways, the
>> 2 services that I mentioned seem to be the only 2 incorrect  
>> datatypes. I
>> created a patch for the registry, but before I committed it, I  
>> wanted to
>> check that I had the general idea down.
>>
>> The patch works like so:
>>
>> User X is registering a datatype. We take all of the direct HAS/HASA
>> articlenames and then traverse the ISA hierarchy towards the root  
>> node
>> ensuring that the articlenames are not used further up the tree.
>>
>> This is how I found those 2 datatypes that I mentioned previously.  
>> I tested
>> my patch against all datatypes in our ontology.
>>
>> If everyone is happy with this, I will commit the patch and update  
>> the
>> documentation.
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: March-26-09 7:31 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> As there is no unique place to put documentation for the purpose or  
>> usage of a member other than its articleName, I'd suggest that the  
>> articleName be mandatory, if only for the purpose of succinctly  
>> describing the relationship between it and the container class.
>>
>> Pieter Neerincx wrote:
>>
>>> Hi,
>>>
>>> If I remember correctly for datatypes it's the combination of the  
>>> object's name and articleName attribute value that must be unique.  
>>> As long as the combi is unique you can distinguish two HAS and a  
>>> HAS-A instance. Therefore if an object has multiple relationships  
>>> involving child element of the same type a unique articleName  
>>> attribute is mandatory but otherwise articleName attributes were  
>>> optional. In addition articleNames in service inputs or outputs  
>>> were mandatory and quite some time ago articleNames became also  
>>> mandatory for primitives no matter whether there was only one  
>>> relationship involving a certain type of primitive or whether  
>>> there were more.
>>>
>>> So AFAIK the GCP_* objects mentioned below are correctly  
>>> registered according to the current specs, but to keep things  
>>> simple it wouldn't hurt to make articleName attributes always  
>>> mandatory. That would render quite some currently used objects  
>>> invalid though...
>>>
>>> Cheers,
>>>
>>> Pi
>>>
>>> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>>>
>>>
>>>> Based on what Paul has said, is it true that the datatypes
>>>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly  
>>>> registered?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul  
>>>> Gordon
>>>> Sent: March-11-09 10:20 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> I can confirm that member articleNames must be unique.  Otherwise  
>>>> there
>>>> would be no way to distinguish two HAS and a HAS-A instance.
>>>>
>>>> Edward Kawas wrote:
>>>>
>>>>> I think that I may have figured it out.
>>>>>
>>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I  
>>>>> think
>>>>>
>>>> that
>>>>
>>>>> the main problem is that the datatype has 2 has relationships.  
>>>>> It has
>>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is  
>>>>> that they
>>>>>
>>>> both
>>>>
>>>>> have the articlename 'has_quality'.
>>>>>
>>>>> I am sure that articlenames in Services have to be unique, but I  
>>>>> can't
>>>>>
>>>> find
>>>>
>>>>> any documentation online saying that articlenames describing  
>>>>> relationships
>>>>> in Datatypes have to be unique as well.
>>>>>
>>>>> So, if articlenames have to be unique, then the registry  
>>>>> inadvertently
>>>>> allowed the registration of datatypes without unique  
>>>>> articlenames for
>>>>> container relationships. Alternatively, if this is allowed, then  
>>>>> a bug was
>>>>> discovered in MoSeS.
>>>>>
>>>>> Anyone have any insight into which one is the correct scenario?
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of  
>>>>> Michael Gerlich
>>>>> Sent: March-11-09 4:14 AM
>>>>> To: Core developer announcements
>>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi Eddie,
>>>>>
>>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this  
>>>>> behavivour
>>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>>
>>>>> This problem also occurs when I run install from a fresh CVS  
>>>>> checkout
>>>>> (including a fresh Biomoby cache directory). All SOTEST*  
>>>>> datatypes are
>>>>> only registered at Central registry, so they are fetched when  
>>>>> Biomoby
>>>>> fills its cache (retrieving datatypes).
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> What version of JAVA are you using? What registry are you  
>>>>>> generating
>>>>>>
>>>> these
>>>>
>>>>>> datatypes from?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of  
>>>>>> Michael Gerlich
>>>>>> Sent: March-10-09 4:28 PM
>>>>>> To: MOBY-dev at lists.open-bio.org
>>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>>>
>>>>>>
>>>>> corresponding
>>>>>
>>>>>
>>>>>> ant tasks, but after fetching all necessary libraries, the  
>>>>>> compilation
>>>>>>
>>>>>>
>>>>> fails
>>>>>
>>>>>
>>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>>
>>>>>> I also encountered this behavior when I tried to run Moses  
>>>>>> Generator for
>>>>>>
>>>>>>
>>>>> one
>>>>>
>>>>>
>>>>>> of my services with an existing Biomoby instance on another  
>>>>>> machine.
>>>>>>
>>>> There
>>>>
>>>>>> the build also fails.
>>>>>> I tested this on 3 different machines, including both Ubuntu  
>>>>>> and XP os.
>>>>>>
>>>>>>
>>>>> The
>>>>>
>>>>>
>>>>>> error log is attached, taken from Dashboad.
>>>>>>
>>>>>> Does anyone encounter similar problems? Should I try cleaning  
>>>>>> Maven
>>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>>
>>>>>> Thanks in advance and regards,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Excerpt follows (100 error messages like this):
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/datat
>>
>>
>>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent()  
>>>>>> in
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene  
>>>>>> cannot
>>>>>>
>>>>>>
>>>>> override
>>>>>
>>>>>
>>>>>> getMoby_Parent() in  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>>> attempting to use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>>   [javac] required:
>>>>>>
>>>>>>
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>>
>>>>>
>>>>>>   [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>>> getMoby_has_quality() in
>>>>>>
>>>>>>
>>>>>>
>> org 
>> .biomoby 
>> .shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>
>>
>>>>>> cannot override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>>>> attempting
>>>>>>
>>>> to
>>>>
>>>>>> use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>>   [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>>   [javac]                              ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>>>
>>>> getMoby_has_quality()
>>>>
>>>>>> in  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>>>
>>>>>>
>>>>> cannot
>>>>>
>>>>>
>>>>>> override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>>>> attempting
>>>>>>
>>>> to
>>>>
>>>>>> use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>>   [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>>   [javac]                              ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_fusion_gene.java:122:  
>>>>>> getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene  
>>>>>> cannot
>>>>>>
>>>>>>
>>>>> override
>>>>>
>>>>>
>>>>>> getMoby_has_quality() in
>>>>>>
>>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>>
>>>>>> attempting to use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>>   [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_rescue_region.java:120:  
>>>>>> getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region  
>>>>>> cannot
>>>>>> override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting  
>>>>>> to use
>>>>>> incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>>   [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>>> getMoby_has_quality() in
>>>>>> org 
>>>>>> .biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>>>
>>>>>>
>>>>> cannot
>>>>>
>>>>>
>>>>>> override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>>>> attempting
>>>>>>
>>>> to
>>>>
>>>>>> use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>>   [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>>> getMoby_part_of() in
>>>>>>
>>>>>>
>>>>>>
>> org 
>> .biomoby 
>> .shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>
>>
>>>>>> cannot override getMoby_part_of() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region;  
>>>>>> attempting to use
>>>>>> incompatible return type
>>>>>>   [javac] found   :
>>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>>   [javac] required:  
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>>   [javac]     public SOTest2_five_prime_coding_exon[]  
>>>>>> getMoby_part_of()
>>>>>>
>>>>>>
>>>>> {
>>>>>
>>>>>
>>>>>>   [javac]                                             ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_five_prime_exon_coding_region.java:114:  
>>>>>> getMoby_part_of()
>>>>>>
>>>> in
>>>>
>>>>>> org 
>>>>>> .biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>>>>>> cannot
>>>>>> override getMoby_part_of() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region;  
>>>>>> attempting to use
>>>>>> incompatible return type
>>>>>>   [javac] found   :
>>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>>   [javac] required:  
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>>   [javac]     public SOTest2_five_prime_coding_exon[]  
>>>>>> getMoby_part_of()
>>>>>>
>>>>>>
>>>>> {
>>>>>
>>>>>
>>>>>>   [javac]
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>> -------------------------------------------------------------
>>> Wageningen University and Research centre (WUR)
>>> Laboratory of Bioinformatics
>>> Transitorium (building 312) room 1034
>>>
>>> Dreijenlaan 3
>>> 6703 HA Wageningen
>>> The Netherlands
>>>
>>> phone:  +31 (0)317-483 060
>>> mobile: +31 (0)6-143 66 783
>>> e-mail: pieter.neerincx at gmail.com
>>> skype:  pieter.online
>>> -------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------




From groscurt at mpiz-koeln.mpg.de  Sat Mar 28 04:58:40 2009
From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth)
Date: Sat, 28 Mar 2009 09:58:40 +0100
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <49C8A77C.1010104@toulouse.inra.fr>
References: <49C8A77C.1010104@toulouse.inra.fr>
Message-ID: <49CDE6C0.9010501@mpiz-koeln.mpg.de>

Hi...

for the password discussion... there is also an authentication system 
available in moby which can be used to secure your webservices - there 
is no need of sending around your login as any kind of 
datatype/parameter of the service....

please have a look at 
http://www.eu-sol.net/science/bioinformatics/tutorials/secure-biomoby-web-services 
...


AND about the curation / deletion of non-used objects in the 
ontology.... BLOW ME DOWN ;-)

Since when does BioMoby supports this idea... I remember last time this 
discussion was a bit the other way of "Oh no... we cant delete them...."

*g

Cheers
Andreas

From jmrodriguez at cnio.es  Mon Mar  2 08:43:09 2009
From: jmrodriguez at cnio.es (jmrodriguez)
Date: Mon, 02 Mar 2009 09:43:09 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>	<49A486A8.1020003@cnio.es>
	<49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
Message-ID: <49AB9C1D.4090104@cnio.es>

Hi Eddie,

For me "moby-wsrf" sounds cool.
But do you mind to send me the link where RFC
says that, please? I did not find that description yet and
I would like read it.

Cheers,
J

Edward Kawas wrote:
> Another thing that I ran into today is that the HTTP header XML for polling,
> requesting results, and destroying the job need a root element. What does
> everyone think about wrapping the header as defined in the RFC with
> <moby-wsrf></moby-wsrf>?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
> Fern?ndez Gonz?lez
> Sent: February-24-09 3:46 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi everybody,
> 	yes, I also agree about no multi-line headers, because they could
> bring many
> compatibility issues, and some "clever" intermediate firewall or proxy could
> misunderstand them.
>
> 	Jos? Mar?a
>
> Edward Kawas wrote:
>   
>> Yeah, I just wanted to throw out the other option for consideration.
>>     
> Besides
>   
>> encoding/decoding overhead, there is also a doubling of the message side
>>     
> if
>   
>> we went that route. I agree, no new lines. 
>>
>> Anyone with any objections?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:57 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> I vote for strongly encouraging no new lines in the XML, and warning 
>> implementers that it might crap out if they include any. I HATE base64 
>> encoding and decoding messages!  Kind of defeats the purpose of using 
>> XML in the message in the first place...
>>
>> BTW, I can confirm after scouring the Web for info that lots of programs 
>> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
>> multi-line headers, even in the last couple of years.
>>
>> Edward Kawas wrote:
>>     
>>> You bring up a very good point. I think that we could either agree to use
>>>       
>> no
>>     
>>> new lines. 
>>>
>>> Another, less desirable, option might be to base64 encode the header... I
>>> like your idea more though (I like sitting on the fence ...)
>>>
>>> Eddie 
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:43 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> According to RFC2616, which references RFC822 section 3.1, you can 
>>> indeed have multi-line header field value, as long as each extra line 
>>> starts with some linear white space.  Otherwise it'll think a new line 
>>> is a new header (and probably a malformed one at that).  There is a 
>>> standard for "folding" and "unfolding" such multi-line headers, which 
>>> essential strips CR and LF out of the message on the receiving end.  I'm 
>>> not sure how well this folding and unfolding protocol is handled by 
>>> various servers and clients, but given that new lines will be stripped 
>>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>>> field XML value should have no new lines, for maximum likelihood of 
>>> transactional success?
>>>
>>> Edward Kawas wrote:
>>>   
>>>       
>>>> Hi Paul,
>>>>
>>>> I was thinking of just treating that XML doc as a string and placing
>>>>         
> that
>   
>>>>     
>>>>         
>>> as
>>>   
>>>       
>>>> the value for the header with key biomoby-wsrf.
>>>>
>>>> Do you think that will work?
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>>> Sent: February-24-09 10:17 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>>
>>>> Hi Eddie,
>>>>
>>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>>> document where you break down sample XML such as "Response from 
>>>> destroying the resource", how exact do you put that XML block in the 
>>>> header?  I though HTTP headers are usually name=value...
>>>>
>>>> Edward Kawas wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hello all,
>>>>>
>>>>> Attached is a draft proposal describing asynchronous post services in
>>>>>     
>>>>>       
>>>>>           
>>>> moby.
>>>>   
>>>>     
>>>>         
>>>>> It is very similar to the RFC for moby-async services, except that it
>>>>>           
> is
>   
>>>>> HTTP POST and not SOAP based.
>>>>>
>>>>> Be harsh but nice!
>>>>>
>>>>> Eddie 
>>>>>   
>>>>>
>>>>>           
> ------------------------------------------------------------------------
>   
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>     
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>   
>>>>     
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>   


-- 
Have you tried CARGO?
http://cargo2.bioinfo.cnio.es/

*********************
Jos? Manuel Rodr?guez Carrasco            e-mail: jmrodriguez at cnio.es
Tlfn:    (+34) 91 732 80 00 ext: 2256     Fax:    (+34) 91 224 69 76
Bioinformatic Unit
Spanish National Cancer Center (CNIO) http://www.cnio.es
Zip Code: 28029
Address: C/. Melchor Fern?ndez Almagro n? 3, Madrid (Spain) 


**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies.



From edward.kawas at gmail.com  Mon Mar  2 15:07:10 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 2 Mar 2009 07:07:10 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49AB9C1D.4090104@cnio.es>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>	<49A486A8.1020003@cnio.es>	<49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
	<49AB9C1D.4090104@cnio.es>
Message-ID: <49abf627.0e538c0a.1fda.62b6@mx.google.com>

I posted the link to the RDF to 

http://biordf.net/~kawas/async_post_services.pdf

It hasn?t been updated yet to include the 'no new lines in the http header'
request.

Eddie


-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of jmrodriguez
Sent: March-02-09 12:43 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi Eddie,

For me "moby-wsrf" sounds cool.
But do you mind to send me the link where RFC
says that, please? I did not find that description yet and
I would like read it.

Cheers,
J

Edward Kawas wrote:
> Another thing that I ran into today is that the HTTP header XML for
polling,
> requesting results, and destroying the job need a root element. What does
> everyone think about wrapping the header as defined in the RFC with
> <moby-wsrf></moby-wsrf>?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
> Fern?ndez Gonz?lez
> Sent: February-24-09 3:46 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi everybody,
> 	yes, I also agree about no multi-line headers, because they could
> bring many
> compatibility issues, and some "clever" intermediate firewall or proxy
could
> misunderstand them.
>
> 	Jos? Mar?a
>
> Edward Kawas wrote:
>   
>> Yeah, I just wanted to throw out the other option for consideration.
>>     
> Besides
>   
>> encoding/decoding overhead, there is also a doubling of the message side
>>     
> if
>   
>> we went that route. I agree, no new lines. 
>>
>> Anyone with any objections?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:57 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> I vote for strongly encouraging no new lines in the XML, and warning 
>> implementers that it might crap out if they include any. I HATE base64 
>> encoding and decoding messages!  Kind of defeats the purpose of using 
>> XML in the message in the first place...
>>
>> BTW, I can confirm after scouring the Web for info that lots of programs 
>> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
>> multi-line headers, even in the last couple of years.
>>
>> Edward Kawas wrote:
>>     
>>> You bring up a very good point. I think that we could either agree to
use
>>>       
>> no
>>     
>>> new lines. 
>>>
>>> Another, less desirable, option might be to base64 encode the header...
I
>>> like your idea more though (I like sitting on the fence ...)
>>>
>>> Eddie 
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:43 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> According to RFC2616, which references RFC822 section 3.1, you can 
>>> indeed have multi-line header field value, as long as each extra line 
>>> starts with some linear white space.  Otherwise it'll think a new line 
>>> is a new header (and probably a malformed one at that).  There is a 
>>> standard for "folding" and "unfolding" such multi-line headers, which 
>>> essential strips CR and LF out of the message on the receiving end.  I'm

>>> not sure how well this folding and unfolding protocol is handled by 
>>> various servers and clients, but given that new lines will be stripped 
>>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>>> field XML value should have no new lines, for maximum likelihood of 
>>> transactional success?
>>>
>>> Edward Kawas wrote:
>>>   
>>>       
>>>> Hi Paul,
>>>>
>>>> I was thinking of just treating that XML doc as a string and placing
>>>>         
> that
>   
>>>>     
>>>>         
>>> as
>>>   
>>>       
>>>> the value for the header with key biomoby-wsrf.
>>>>
>>>> Do you think that will work?
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>>> Sent: February-24-09 10:17 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>>
>>>> Hi Eddie,
>>>>
>>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>>> document where you break down sample XML such as "Response from 
>>>> destroying the resource", how exact do you put that XML block in the 
>>>> header?  I though HTTP headers are usually name=value...
>>>>
>>>> Edward Kawas wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hello all,
>>>>>
>>>>> Attached is a draft proposal describing asynchronous post services in
>>>>>     
>>>>>       
>>>>>           
>>>> moby.
>>>>   
>>>>     
>>>>         
>>>>> It is very similar to the RFC for moby-async services, except that it
>>>>>           
> is
>   
>>>>> HTTP POST and not SOAP based.
>>>>>
>>>>> Be harsh but nice!
>>>>>
>>>>> Eddie 
>>>>>   
>>>>>
>>>>>           
> ------------------------------------------------------------------------
>   
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>     
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>   
>>>>     
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>   


-- 
Have you tried CARGO?
http://cargo2.bioinfo.cnio.es/

*********************
Jos? Manuel Rodr?guez Carrasco            e-mail: jmrodriguez at cnio.es
Tlfn:    (+34) 91 732 80 00 ext: 2256     Fax:    (+34) 91 224 69 76
Bioinformatic Unit
Spanish National Cancer Center (CNIO) http://www.cnio.es
Zip Code: 28029
Address: C/. Melchor Fern?ndez Almagro n? 3, Madrid (Spain) 


**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los
ficheros adjuntos, pueden contener informaci?n protegida para el uso
exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o
cualquier otro tipo de transmisi?n por parte de otra persona que no sea el
destinatario. Si usted recibe por error este correo, se ruega comunicarlo al
remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may
contain confidential and privileged information for the sole use of the
designated recipient named above. Distribution, reproduction or any other
use of this transmission by any party other than the intended recipient is
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev




From edward.kawas at gmail.com  Fri Mar  6 14:49:21 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 6 Mar 2009 06:49:21 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49AB9C1D.4090104@cnio.es>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>	<49A486A8.1020003@cnio.es>	<49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>
	<49AB9C1D.4090104@cnio.es>
Message-ID: <49b137f6.28d7720a.5387.2c38@mx.google.com>

Just pinging everyone out there to see what the opinions are on this RFC. 

Did anyone find any obvious errors or are there any objections? 

Thanks,

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of jmrodriguez
Sent: March-02-09 12:43 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi Eddie,

For me "moby-wsrf" sounds cool.
But do you mind to send me the link where RFC
says that, please? I did not find that description yet and
I would like read it.

Cheers,
J

Edward Kawas wrote:
> Another thing that I ran into today is that the HTTP header XML for
polling,
> requesting results, and destroying the job need a root element. What does
> everyone think about wrapping the header as defined in the RFC with
> <moby-wsrf></moby-wsrf>?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
> Fern?ndez Gonz?lez
> Sent: February-24-09 3:46 PM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi everybody,
> 	yes, I also agree about no multi-line headers, because they could
> bring many
> compatibility issues, and some "clever" intermediate firewall or proxy
could
> misunderstand them.
>
> 	Jos? Mar?a
>
> Edward Kawas wrote:
>   
>> Yeah, I just wanted to throw out the other option for consideration.
>>     
> Besides
>   
>> encoding/decoding overhead, there is also a doubling of the message side
>>     
> if
>   
>> we went that route. I agree, no new lines. 
>>
>> Anyone with any objections?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:57 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> I vote for strongly encouraging no new lines in the XML, and warning 
>> implementers that it might crap out if they include any. I HATE base64 
>> encoding and decoding messages!  Kind of defeats the purpose of using 
>> XML in the message in the first place...
>>
>> BTW, I can confirm after scouring the Web for info that lots of programs 
>> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
>> multi-line headers, even in the last couple of years.
>>
>> Edward Kawas wrote:
>>     
>>> You bring up a very good point. I think that we could either agree to
use
>>>       
>> no
>>     
>>> new lines. 
>>>
>>> Another, less desirable, option might be to base64 encode the header...
I
>>> like your idea more though (I like sitting on the fence ...)
>>>
>>> Eddie 
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:43 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> According to RFC2616, which references RFC822 section 3.1, you can 
>>> indeed have multi-line header field value, as long as each extra line 
>>> starts with some linear white space.  Otherwise it'll think a new line 
>>> is a new header (and probably a malformed one at that).  There is a 
>>> standard for "folding" and "unfolding" such multi-line headers, which 
>>> essential strips CR and LF out of the message on the receiving end.  I'm

>>> not sure how well this folding and unfolding protocol is handled by 
>>> various servers and clients, but given that new lines will be stripped 
>>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>>> field XML value should have no new lines, for maximum likelihood of 
>>> transactional success?
>>>
>>> Edward Kawas wrote:
>>>   
>>>       
>>>> Hi Paul,
>>>>
>>>> I was thinking of just treating that XML doc as a string and placing
>>>>         
> that
>   
>>>>     
>>>>         
>>> as
>>>   
>>>       
>>>> the value for the header with key biomoby-wsrf.
>>>>
>>>> Do you think that will work?
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>>> Sent: February-24-09 10:17 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>>
>>>> Hi Eddie,
>>>>
>>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>>> document where you break down sample XML such as "Response from 
>>>> destroying the resource", how exact do you put that XML block in the 
>>>> header?  I though HTTP headers are usually name=value...
>>>>
>>>> Edward Kawas wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hello all,
>>>>>
>>>>> Attached is a draft proposal describing asynchronous post services in
>>>>>     
>>>>>       
>>>>>           
>>>> moby.
>>>>   
>>>>     
>>>>         
>>>>> It is very similar to the RFC for moby-async services, except that it
>>>>>           
> is
>   
>>>>> HTTP POST and not SOAP based.
>>>>>
>>>>> Be harsh but nice!
>>>>>
>>>>> Eddie 
>>>>>   
>>>>>
>>>>>           
> ------------------------------------------------------------------------
>   
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>     
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>   
>>>>     
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>   


-- 
Have you tried CARGO?
http://cargo2.bioinfo.cnio.es/

*********************
Jos? Manuel Rodr?guez Carrasco            e-mail: jmrodriguez at cnio.es
Tlfn:    (+34) 91 732 80 00 ext: 2256     Fax:    (+34) 91 224 69 76
Bioinformatic Unit
Spanish National Cancer Center (CNIO) http://www.cnio.es
Zip Code: 28029
Address: C/. Melchor Fern?ndez Almagro n? 3, Madrid (Spain) 


**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los
ficheros adjuntos, pueden contener informaci?n protegida para el uso
exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o
cualquier otro tipo de transmisi?n por parte de otra persona que no sea el
destinatario. Si usted recibe por error este correo, se ruega comunicarlo al
remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may
contain confidential and privileged information for the sole use of the
designated recipient named above. Distribution, reproduction or any other
use of this transmission by any party other than the intended recipient is
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev




From MichaelGerlich at gmx.de  Tue Mar 10 23:27:38 2009
From: MichaelGerlich at gmx.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 00:27:38 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
Message-ID: <000001c9a1d7$ccf5a120$66e0e360$@de>

Hi all,

I checked out Biomoby from CVS and tried to install it via the corresponding
ant tasks, but after fetching all necessary libraries, the compilation fails
with a lot of error messages regarding datatypes SOTEST*.

I also encountered this behavior when I tried to run Moses Generator for one
of my services with an existing Biomoby instance on another machine. There
the build also fails. 
I tested this on 3 different machines, including both Ubuntu and XP os. The
error log is attached, taken from Dashboad.

Does anyone encounter similar problems? Should I try cleaning Maven
repository, Biomoby cache and/or new Eclipse workspace?

Thanks in advance and regards,
Michael


Excerpt follows (100 error messages like this):

home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot override
getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
    [javac] required: org.biomoby.shared.datatypes.SOTest2_engineered_region
    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_foreign_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
cannot override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot override
getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
cannot override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                                             ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                            



From martin.senger at gmail.com  Tue Mar 10 23:39:42 2009
From: martin.senger at gmail.com (Martin Senger)
Date: Wed, 11 Mar 2009 00:39:42 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <000001c9a1d7$ccf5a120$66e0e360$@de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
Message-ID: <4d93f07c0903101639q10f79c92wba74163dc3ace4f4@mail.gmail.com>

The problem is known and was discussed in the past. Perhaps Eddie remembers
it (because I don't) - it has something to do (I think) with not cleaning
generated MOses code, perhaps also relevant to the local cache. I will be
back on inet in couple of days - and I will try to be more helpful if the
problem is not solved until then.

Cheers,
Martin

-- 
Martin Senger
email: martin.senger at gmail.com,m.senger at cgiar.org
skype: martinsenger
Sent from: Paris J France.


From edward.kawas at gmail.com  Wed Mar 11 00:49:27 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 10 Mar 2009 17:49:27 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <000001c9a1d7$ccf5a120$66e0e360$@de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
Message-ID: <49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>

Hi Michael,

What version of JAVA are you using? What registry are you generating these
datatypes from?

Thanks,

Eddie 

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
Sent: March-10-09 4:28 PM
To: MOBY-dev at lists.open-bio.org
Subject: [MOBY-dev] error installing Biomoby via ant

Hi all,

I checked out Biomoby from CVS and tried to install it via the corresponding
ant tasks, but after fetching all necessary libraries, the compilation fails
with a lot of error messages regarding datatypes SOTEST*.

I also encountered this behavior when I tried to run Moses Generator for one
of my services with an existing Biomoby instance on another machine. There
the build also fails. 
I tested this on 3 different machines, including both Ubuntu and XP os. The
error log is attached, taken from Dashboad.

Does anyone encounter similar problems? Should I try cleaning Maven
repository, Biomoby cache and/or new Eclipse workspace?

Thanks in advance and regards,
Michael


Excerpt follows (100 error messages like this):

home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot override
getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
    [javac] required: org.biomoby.shared.datatypes.SOTest2_engineered_region
    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_foreign_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
cannot override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
    [javac]                              ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot override
getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
attempting to use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_engineered_transposable_element.java:121:
getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element cannot
override getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
use incompatible return type
    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
    [javac]                                 ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
cannot override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                                             ^
    [javac]
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
override getMoby_part_of() in
org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
incompatible return type
    [javac] found   :
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
    [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
    [javac]                            

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From mgerlich at ipb-halle.de  Wed Mar 11 11:14:14 2009
From: mgerlich at ipb-halle.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 12:14:14 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
Message-ID: <49B79D06.5090208@ipb-halle.de>

Hi Eddie,

I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
generated services and axis 1.4 and Tomcat5.5).

This problem also occurs when I run install from a fresh CVS checkout 
(including a fresh Biomoby cache directory). All SOTEST* datatypes are 
only registered at Central registry, so they are fetched when Biomoby 
fills its cache (retrieving datatypes).

Regards,

Michael

> Hi Michael,
>
> What version of JAVA are you using? What registry are you generating these
> datatypes from?
>
> Thanks,
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-10-09 4:28 PM
> To: MOBY-dev at lists.open-bio.org
> Subject: [MOBY-dev] error installing Biomoby via ant
>
> Hi all,
>
> I checked out Biomoby from CVS and tried to install it via the corresponding
> ant tasks, but after fetching all necessary libraries, the compilation fails
> with a lot of error messages regarding datatypes SOTEST*.
>
> I also encountered this behavior when I tried to run Moses Generator for one
> of my services with an existing Biomoby instance on another machine. There
> the build also fails. 
> I tested this on 3 different machines, including both Ubuntu and XP os. The
> error log is attached, taken from Dashboad.
>
> Does anyone encounter similar problems? Should I try cleaning Maven
> repository, Biomoby cache and/or new Eclipse workspace?
>
> Thanks in advance and regards,
> Michael
>
>
> Excerpt follows (100 error messages like this):
>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot override
> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_engineered_region
>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_foreign_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
> cannot override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot override
> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
> incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
> getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
> cannot override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
>     [javac]                                             ^
>     [javac]
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
> override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of() {
>     [javac]                            
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>   


-- 

Michael Gerlich
Group Bioinformatics & Mass Spectrometry
Leibniz Institute of Plant Biochemistry
06120 Halle, Germany



From edward.kawas at gmail.com  Wed Mar 11 15:40:33 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 08:40:33 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B79D06.5090208@ipb-halle.de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
Message-ID: <49b7db8a.27ba720a.09b1.ffffacef@mx.google.com>

Okay, I have the same problem right now. I deleted my cache, my repository,
etc and building datatypes still fails. I was waiting to solve the problem
before replying, but I haven't been able to figure it out. I will respond
once I do.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
Sent: March-11-09 4:14 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

Hi Eddie,

I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
generated services and axis 1.4 and Tomcat5.5).

This problem also occurs when I run install from a fresh CVS checkout 
(including a fresh Biomoby cache directory). All SOTEST* datatypes are 
only registered at Central registry, so they are fetched when Biomoby 
fills its cache (retrieving datatypes).

Regards,

Michael

> Hi Michael,
>
> What version of JAVA are you using? What registry are you generating these
> datatypes from?
>
> Thanks,
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-10-09 4:28 PM
> To: MOBY-dev at lists.open-bio.org
> Subject: [MOBY-dev] error installing Biomoby via ant
>
> Hi all,
>
> I checked out Biomoby from CVS and tried to install it via the
corresponding
> ant tasks, but after fetching all necessary libraries, the compilation
fails
> with a lot of error messages regarding datatypes SOTEST*.
>
> I also encountered this behavior when I tried to run Moses Generator for
one
> of my services with an existing Biomoby instance on another machine. There
> the build also fails. 
> I tested this on 3 different machines, including both Ubuntu and XP os.
The
> error log is attached, taken from Dashboad.
>
> Does anyone encounter similar problems? Should I try cleaning Maven
> repository, Biomoby cache and/or new Eclipse workspace?
>
> Thanks in advance and regards,
> Michael
>
>
> Excerpt follows (100 error messages like this):
>
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
override
> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>     [javac] required:
org.biomoby.shared.datatypes.SOTest2_engineered_region
>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_foreign_transposable_element.java:121:
> getMoby_has_quality() in
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
> cannot override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
override
> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
> incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
> getMoby_part_of() in
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
> cannot override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                                             ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
> override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                            
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>   


-- 

Michael Gerlich
Group Bioinformatics & Mass Spectrometry
Leibniz Institute of Plant Biochemistry
06120 Halle, Germany

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From edward.kawas at gmail.com  Wed Mar 11 17:00:29 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 10:00:29 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B79D06.5090208@ipb-halle.de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
Message-ID: <49b7ee46.02578c0a.1260.ffff816d@mx.google.com>

I think that I may have figured it out.

Using the datatype SOTest2_validated_cDNA_clone as an example, I think that
the main problem is that the datatype has 2 has relationships. It has
SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they both
have the articlename 'has_quality'.

I am sure that articlenames in Services have to be unique, but I can't find
any documentation online saying that articlenames describing relationships
in Datatypes have to be unique as well.

So, if articlenames have to be unique, then the registry inadvertently
allowed the registration of datatypes without unique articlenames for
container relationships. Alternatively, if this is allowed, then a bug was
discovered in MoSeS.

Anyone have any insight into which one is the correct scenario?
 
Eddie


-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
Sent: March-11-09 4:14 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

Hi Eddie,

I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
generated services and axis 1.4 and Tomcat5.5).

This problem also occurs when I run install from a fresh CVS checkout 
(including a fresh Biomoby cache directory). All SOTEST* datatypes are 
only registered at Central registry, so they are fetched when Biomoby 
fills its cache (retrieving datatypes).

Regards,

Michael

> Hi Michael,
>
> What version of JAVA are you using? What registry are you generating these
> datatypes from?
>
> Thanks,
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-10-09 4:28 PM
> To: MOBY-dev at lists.open-bio.org
> Subject: [MOBY-dev] error installing Biomoby via ant
>
> Hi all,
>
> I checked out Biomoby from CVS and tried to install it via the
corresponding
> ant tasks, but after fetching all necessary libraries, the compilation
fails
> with a lot of error messages regarding datatypes SOTEST*.
>
> I also encountered this behavior when I tried to run Moses Generator for
one
> of my services with an existing Biomoby instance on another machine. There
> the build also fails. 
> I tested this on 3 different machines, including both Ubuntu and XP os.
The
> error log is attached, taken from Dashboad.
>
> Does anyone encounter similar problems? Should I try cleaning Maven
> repository, Biomoby cache and/or new Eclipse workspace?
>
> Thanks in advance and regards,
> Michael
>
>
> Excerpt follows (100 error messages like this):
>
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
override
> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>     [javac] required:
org.biomoby.shared.datatypes.SOTest2_engineered_region
>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_foreign_transposable_element.java:121:
> getMoby_has_quality() in
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
> cannot override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>     [javac]                              ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
override
> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
> attempting to use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
> incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_engineered_transposable_element.java:121:
> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
cannot
> override getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
> use incompatible return type
>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>     [javac]                                 ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
> getMoby_part_of() in
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
> cannot override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                                             ^
>     [javac]
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
> override getMoby_part_of() in
> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
> incompatible return type
>     [javac] found   :
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
{
>     [javac]                            
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>   


-- 

Michael Gerlich
Group Bioinformatics & Mass Spectrometry
Leibniz Institute of Plant Biochemistry
06120 Halle, Germany

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From gordonp at ucalgary.ca  Wed Mar 11 17:19:59 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 11 Mar 2009 11:19:59 -0600
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
Message-ID: <49B7F2BF.2060801@ucalgary.ca>

I can confirm that member articleNames must be unique.  Otherwise there 
would be no way to distinguish two HAS and a HAS-A instance.

Edward Kawas wrote:
> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't find
> any documentation online saying that articlenames describing relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
>  
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout 
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are 
> only registered at Central registry, so they are fetched when Biomoby 
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>   
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
>>     
> corresponding
>   
>> ant tasks, but after fetching all necessary libraries, the compilation
>>     
> fails
>   
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
>>     
> one
>   
>> of my services with an existing Biomoby instance on another machine. There
>> the build also fails. 
>> I tested this on 3 different machines, including both Ubuntu and XP os.
>>     
> The
>   
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>>     
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>   
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>     
> override
>   
>> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>   
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>   
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_foreign_transposable_element.java:112: getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>     
> override
>   
>> getMoby_has_quality() in org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>>     
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>   
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                                             ^
>>     [javac]
>>
>>     
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                            
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>   
>>     
>
>
>   


From edward.kawas at gmail.com  Wed Mar 11 17:47:37 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 10:47:37 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B7F2BF.2060801@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
Message-ID: <49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>

Thanks Paul. Then there is a bug in the registry.

Michael, you may need to re-register your datatypes, taking into account
that articlenames must be unique. 

While I am at it, a wise man once said that "if you 'inherit' from Object
and don't add any new fields, then you have used the Object ontology
incorrectly." Hmm, actually I think Mark said this ;-)

For instance, if you have a service that consumes SOTest_DNA, do you really
mean that the service consumes DNASequence under the namespace SOTest?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: March-11-09 10:20 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

I can confirm that member articleNames must be unique.  Otherwise there 
would be no way to distinguish two HAS and a HAS-A instance.

Edward Kawas wrote:
> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't
find
> any documentation online saying that articlenames describing relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
>  
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout 
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are 
> only registered at Central registry, so they are fetched when Biomoby 
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>   
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating
these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
>>     
> corresponding
>   
>> ant tasks, but after fetching all necessary libraries, the compilation
>>     
> fails
>   
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
>>     
> one
>   
>> of my services with an existing Biomoby instance on another machine.
There
>> the build also fails. 
>> I tested this on 3 different machines, including both Ubuntu and XP os.
>>     
> The
>   
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>>     
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>   
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>     
> override
>   
>> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>   
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>   
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_foreign_transposable_element.java:112:
getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>     
> override
>   
>> getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>   
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                                             ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                            
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>   
>>     
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From markw at illuminae.com  Wed Mar 11 17:43:41 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 10:43:41 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
Message-ID: <op.uqm163nqnbznux@mark.ubic.ubc.ca>

I believe that the MOBY Central code is supposed to check that  
articlenames are unique... but it may be bugged!

M



On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:

> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think  
> that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they  
> both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't  
> find
> any documentation online saying that articlenames describing  
> relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug  
> was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
> only registered at Central registry, so they are fetched when Biomoby
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating  
>> these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
> corresponding
>> ant tasks, but after fetching all necessary libraries, the compilation
> fails
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
> one
>> of my services with an existing Biomoby instance on another machine.  
>> There
>> the build also fails.
>> I tested this on 3 different machines, including both Ubuntu and XP os.
> The
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
> override
>> getMoby_Parent() in  
>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_foreign_transposable_element.java:112:  
>> getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
> override
>> getMoby_has_quality() in  
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]                                             ^
>>     [javac]
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>> cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>
>




From markw at illuminae.com  Wed Mar 11 18:07:10 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 11:07:10 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
	<49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>
Message-ID: <op.uqm298hqnbznux@mark.ubic.ubc.ca>

On Wed, 11 Mar 2009 10:47:37 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:


> While I am at it, a wise man once said that "if you 'inherit' from Object
> and don't add any new fields, then you have used the Object ontology
> incorrectly." Hmm, actually I think Mark said this ;-)


Yes, I did... and I still believe it!  The "exception" is with the  
IRRI/GCP objects, but they have willingly accepted the limitations to  
interoperability that this decision creates.


> For instance, if you have a service that consumes SOTest_DNA, do you  
> really
> mean that the service consumes DNASequence under the namespace SOTest?


Without even LOOKING at the service, I bet my first-born that Eddie is  
right...  The confusion of object and namespace is quite common,  
unfortunately :-(

M


From edward.kawas at gmail.com  Wed Mar 11 18:08:51 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 11:08:51 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm298hqnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49b7f952.02578c0a.12ff.ffffe42c@mx.google.com>
	<op.uqm298hqnbznux@mark.ubic.ubc.ca>
Message-ID: <49b7fe4c.25bb720a.2b7c.ffffb0ec@mx.google.com>

So just to be clear, right now there aren't any services registered that use
those datatypes. I was just throwing out an assumption.

Thanks for betting the first born ;-)

Eddie


-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 11:07 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

On Wed, 11 Mar 2009 10:47:37 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:


> While I am at it, a wise man once said that "if you 'inherit' from Object
> and don't add any new fields, then you have used the Object ontology
> incorrectly." Hmm, actually I think Mark said this ;-)


Yes, I did... and I still believe it!  The "exception" is with the  
IRRI/GCP objects, but they have willingly accepted the limitations to  
interoperability that this decision creates.


> For instance, if you have a service that consumes SOTest_DNA, do you  
> really
> mean that the service consumes DNASequence under the namespace SOTest?


Without even LOOKING at the service, I bet my first-born that Eddie is  
right...  The confusion of object and namespace is quite common,  
unfortunately :-(

M
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From MichaelGerlich at gmx.de  Wed Mar 11 18:21:08 2009
From: MichaelGerlich at gmx.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 19:21:08 +0100
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm163nqnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
Message-ID: <001e01c9a276$283878c0$78a96a40$@de>

Hi,

those datatypes are neither mine nor do I use them. 
They are registered at some French site. I don't use any of these SOTEST*
datatypes. 
I just can't get a fresh Biomoby checkout "installed" correctly or generate
Moses code for one of my services (using pre-defined datatypes like
ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel, which
is derived from Array and having unique field names ;) ).

Is there a way to circumvent these SOTEST* datatypes when running Moses
and/or install ant script?

Kind regards,
Michael



-----Urspr?ngliche Nachricht-----
Von: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark Wilkinson
Gesendet: Mittwoch, 11. M?rz 2009 18:44
An: Core developer announcements
Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

I believe that the MOBY Central code is supposed to check that  
articlenames are unique... but it may be bugged!

M



On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:

> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think  
> that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they  
> both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't  
> find
> any documentation online saying that articlenames describing  
> relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug  
> was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
> only registered at Central registry, so they are fetched when Biomoby
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating  
>> these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
> corresponding
>> ant tasks, but after fetching all necessary libraries, the compilation
> fails
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
> one
>> of my services with an existing Biomoby instance on another machine.  
>> There
>> the build also fails.
>> I tested this on 3 different machines, including both Ubuntu and XP os.
> The
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
> override
>> getMoby_Parent() in  
>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_foreign_transposable_element.java:112:  
>> getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
> override
>> getMoby_has_quality() in  
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
> cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting  
>> to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]                                             ^
>>     [javac]
>>
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()  
>> in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>> cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to  
>> use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[]  
>> getMoby_part_of()
> {
>>     [javac]
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>
>


_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev




From markw at illuminae.com  Wed Mar 11 18:31:59 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 11:31:59 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <001e01c9a276$283878c0$78a96a40$@de>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
	<001e01c9a276$283878c0$78a96a40$@de>
Message-ID: <op.uqm4flhynbznux@mark.ubic.ubc.ca>

Eddie, if no service uses them, and if no object uses them, then we should  
probably consider deleting them...  this is allowed by the API.

M



On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich  
<MichaelGerlich at gmx.de> wrote:

> Hi,
>
> those datatypes are neither mine nor do I use them.
> They are registered at some French site. I don't use any of these SOTEST*
> datatypes.
> I just can't get a fresh Biomoby checkout "installed" correctly or  
> generate
> Moses code for one of my services (using pre-defined datatypes like
> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,  
> which
> is derived from Array and having unique field names ;) ).
>
> Is there a way to circumvent these SOTEST* datatypes when running Moses
> and/or install ant script?
>
> Kind regards,
> Michael
>
>
>
> -----Urspr?ngliche Nachricht-----
> Von: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark  
> Wilkinson
> Gesendet: Mittwoch, 11. M?rz 2009 18:44
> An: Core developer announcements
> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>
> I believe that the MOBY Central code is supposed to check that
> articlenames are unique... but it may be bugged!
>
> M
>
>
>
> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>
> wrote:
>
>> I think that I may have figured it out.
>>
>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>> the main problem is that the datatype has 2 has relationships. It has
>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>> have the articlename 'has_quality'.
>>
>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>> any documentation online saying that articlenames describing
>> relationships
>> in Datatypes have to be unique as well.
>>
>> So, if articlenames have to be unique, then the registry inadvertently
>> allowed the registration of datatypes without unique articlenames for
>> container relationships. Alternatively, if this is allowed, then a bug
>> was
>> discovered in MoSeS.
>>
>> Anyone have any insight into which one is the correct scenario?
>> Eddie
>>
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-11-09 4:14 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi Eddie,
>>
>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>> generated services and axis 1.4 and Tomcat5.5).
>>
>> This problem also occurs when I run install from a fresh CVS checkout
>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>> only registered at Central registry, so they are fetched when Biomoby
>> fills its cache (retrieving datatypes).
>>
>> Regards,
>>
>> Michael
>>
>>> Hi Michael,
>>>
>>> What version of JAVA are you using? What registry are you generating
>>> these
>>> datatypes from?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>> Gerlich
>>> Sent: March-10-09 4:28 PM
>>> To: MOBY-dev at lists.open-bio.org
>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi all,
>>>
>>> I checked out Biomoby from CVS and tried to install it via the
>> corresponding
>>> ant tasks, but after fetching all necessary libraries, the compilation
>> fails
>>> with a lot of error messages regarding datatypes SOTEST*.
>>>
>>> I also encountered this behavior when I tried to run Moses Generator  
>>> for
>> one
>>> of my services with an existing Biomoby instance on another machine.
>>> There
>>> the build also fails.
>>> I tested this on 3 different machines, including both Ubuntu and XP os.
>> The
>>> error log is attached, taken from Dashboad.
>>>
>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>
>>> Thanks in advance and regards,
>>> Michael
>>>
>>>
>>> Excerpt follows (100 error messages like this):
>>>
>>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>> override
>>> getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>     [javac] required:
>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>> getMoby_has_quality() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>> cannot override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_foreign_transposable_element.java:112:
>>> getMoby_has_quality()
>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>> override
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>> incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_transposable_element.java:121:
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>> getMoby_part_of() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>> cannot override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]                                             ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>> cannot
>>> override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev




From edward.kawas at gmail.com  Wed Mar 11 18:32:11 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 11:32:11 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm4flhynbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>
	<op.uqm4flhynbznux@mark.ubic.ubc.ca>
Message-ID: <49b803c4.1a36720a.27ca.ffff822e@mx.google.com>

I feel bad doing so, but ok. I will back up their definitions and then remove them.

When I am done, I will let everyone know.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 11:32 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Eddie, if no service uses them, and if no object uses them, then we should  
probably consider deleting them...  this is allowed by the API.

M



On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich  
<MichaelGerlich at gmx.de> wrote:

> Hi,
>
> those datatypes are neither mine nor do I use them.
> They are registered at some French site. I don't use any of these SOTEST*
> datatypes.
> I just can't get a fresh Biomoby checkout "installed" correctly or  
> generate
> Moses code for one of my services (using pre-defined datatypes like
> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,  
> which
> is derived from Array and having unique field names ;) ).
>
> Is there a way to circumvent these SOTEST* datatypes when running Moses
> and/or install ant script?
>
> Kind regards,
> Michael
>
>
>
> -----Urspr?ngliche Nachricht-----
> Von: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark  
> Wilkinson
> Gesendet: Mittwoch, 11. M?rz 2009 18:44
> An: Core developer announcements
> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>
> I believe that the MOBY Central code is supposed to check that
> articlenames are unique... but it may be bugged!
>
> M
>
>
>
> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas <edward.kawas at gmail.com>
> wrote:
>
>> I think that I may have figured it out.
>>
>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>> the main problem is that the datatype has 2 has relationships. It has
>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>> have the articlename 'has_quality'.
>>
>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>> any documentation online saying that articlenames describing
>> relationships
>> in Datatypes have to be unique as well.
>>
>> So, if articlenames have to be unique, then the registry inadvertently
>> allowed the registration of datatypes without unique articlenames for
>> container relationships. Alternatively, if this is allowed, then a bug
>> was
>> discovered in MoSeS.
>>
>> Anyone have any insight into which one is the correct scenario?
>> Eddie
>>
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-11-09 4:14 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi Eddie,
>>
>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>> generated services and axis 1.4 and Tomcat5.5).
>>
>> This problem also occurs when I run install from a fresh CVS checkout
>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>> only registered at Central registry, so they are fetched when Biomoby
>> fills its cache (retrieving datatypes).
>>
>> Regards,
>>
>> Michael
>>
>>> Hi Michael,
>>>
>>> What version of JAVA are you using? What registry are you generating
>>> these
>>> datatypes from?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>> Gerlich
>>> Sent: March-10-09 4:28 PM
>>> To: MOBY-dev at lists.open-bio.org
>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi all,
>>>
>>> I checked out Biomoby from CVS and tried to install it via the
>> corresponding
>>> ant tasks, but after fetching all necessary libraries, the compilation
>> fails
>>> with a lot of error messages regarding datatypes SOTEST*.
>>>
>>> I also encountered this behavior when I tried to run Moses Generator  
>>> for
>> one
>>> of my services with an existing Biomoby instance on another machine.
>>> There
>>> the build also fails.
>>> I tested this on 3 different machines, including both Ubuntu and XP os.
>> The
>>> error log is attached, taken from Dashboad.
>>>
>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>
>>> Thanks in advance and regards,
>>> Michael
>>>
>>>
>>> Excerpt follows (100 error messages like this):
>>>
>>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>> override
>>> getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>     [javac] required:
>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>> getMoby_has_quality() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>> cannot override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_foreign_transposable_element.java:112:
>>> getMoby_has_quality()
>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>     [javac]                              ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>> override
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>> attempting to use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>> incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_engineered_transposable_element.java:121:
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>> cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
>>> to
>>> use incompatible return type
>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>     [javac]                                 ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>> getMoby_part_of() in
>>>
>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>> cannot override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]                                             ^
>>>     [javac]
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
>>> in
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>> cannot
>>> override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>> use
>>> incompatible return type
>>>     [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>> getMoby_part_of()
>> {
>>>     [javac]
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev


_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev




From markw at illuminae.com  Wed Mar 11 18:38:39 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 11:38:39 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
	<001e01c9a276$283878c0$78a96a40$@de>
	<op.uqm4flhynbznux@mark.ubic.ubc.ca>
	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
Message-ID: <op.uqm4qprnnbznux@mark.ubic.ubc.ca>

No need to feel bad!  This is *precisely* how Moby ontology curation is  
supposed to work!  Objects that are not being used, or that have a  
"better" object defined elsewhere in the ontology, should be deleted by  
the author of the object, or by anyone who finds it.  This is the Web 2.0  
aspect of Moby that hasn't really been working well (probably because  
everyone feels the same as you about deleting other people's stuff...).   
The API prevents you from deleting objects that *are* being used, but  
that's the only security we guarantee in Moby.

M



On Wed, 11 Mar 2009 11:32:11 -0700, Edward Kawas <edward.kawas at gmail.com>  
wrote:

> I feel bad doing so, but ok. I will back up their definitions and then  
> remove them.
>
> When I am done, I will let everyone know.
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org  
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
> Sent: March-11-09 11:32 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>
> Eddie, if no service uses them, and if no object uses them, then we  
> should
> probably consider deleting them...  this is allowed by the API.
>
> M
>
>
>
> On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich
> <MichaelGerlich at gmx.de> wrote:
>
>> Hi,
>>
>> those datatypes are neither mine nor do I use them.
>> They are registered at some French site. I don't use any of these  
>> SOTEST*
>> datatypes.
>> I just can't get a fresh Biomoby checkout "installed" correctly or
>> generate
>> Moses code for one of my services (using pre-defined datatypes like
>> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,
>> which
>> is derived from Array and having unique field names ;) ).
>>
>> Is there a way to circumvent these SOTEST* datatypes when running Moses
>> and/or install ant script?
>>
>> Kind regards,
>> Michael
>>
>>
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark
>> Wilkinson
>> Gesendet: Mittwoch, 11. M?rz 2009 18:44
>> An: Core developer announcements
>> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>>
>> I believe that the MOBY Central code is supposed to check that
>> articlenames are unique... but it may be bugged!
>>
>> M
>>
>>
>>
>> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas  
>> <edward.kawas at gmail.com>
>> wrote:
>>
>>> I think that I may have figured it out.
>>>
>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>> that
>>> the main problem is that the datatype has 2 has relationships. It has
>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>> both
>>> have the articlename 'has_quality'.
>>>
>>> I am sure that articlenames in Services have to be unique, but I can't
>>> find
>>> any documentation online saying that articlenames describing
>>> relationships
>>> in Datatypes have to be unique as well.
>>>
>>> So, if articlenames have to be unique, then the registry inadvertently
>>> allowed the registration of datatypes without unique articlenames for
>>> container relationships. Alternatively, if this is allowed, then a bug
>>> was
>>> discovered in MoSeS.
>>>
>>> Anyone have any insight into which one is the correct scenario?
>>> Eddie
>>>
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>> Gerlich
>>> Sent: March-11-09 4:14 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi Eddie,
>>>
>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>> generated services and axis 1.4 and Tomcat5.5).
>>>
>>> This problem also occurs when I run install from a fresh CVS checkout
>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>> only registered at Central registry, so they are fetched when Biomoby
>>> fills its cache (retrieving datatypes).
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>> Hi Michael,
>>>>
>>>> What version of JAVA are you using? What registry are you generating
>>>> these
>>>> datatypes from?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>> Gerlich
>>>> Sent: March-10-09 4:28 PM
>>>> To: MOBY-dev at lists.open-bio.org
>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi all,
>>>>
>>>> I checked out Biomoby from CVS and tried to install it via the
>>> corresponding
>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>> fails
>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>
>>>> I also encountered this behavior when I tried to run Moses Generator
>>>> for
>>> one
>>>> of my services with an existing Biomoby instance on another machine.
>>>> There
>>>> the build also fails.
>>>> I tested this on 3 different machines, including both Ubuntu and XP  
>>>> os.
>>> The
>>>> error log is attached, taken from Dashboad.
>>>>
>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>
>>>> Thanks in advance and regards,
>>>> Michael
>>>>
>>>>
>>>> Excerpt follows (100 error messages like this):
>>>>
>>>>
>>>
>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>> override
>>>> getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>> attempting to use incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>     [javac] required:
>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>>> cannot override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>> attempting
>>>> to
>>>> use incompatible return type
>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>     [javac]                              ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>> getMoby_has_quality()
>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>> cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>> attempting
>>>> to
>>>> use incompatible return type
>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>     [javac]                              ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality()  
>>>> in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>> override
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>> attempting to use incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality()
>>>> in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>> incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>> cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>> attempting
>>>> to
>>>> use incompatible return type
>>>>     [javac] found   :  
>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>     [javac]                                 ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>> getMoby_part_of() in
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>>> cannot override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>> use
>>>> incompatible return type
>>>>     [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>     [javac] required:  
>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>> getMoby_part_of()
>>> {
>>>>     [javac]                                             ^
>>>>     [javac]
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>>>> types/SOTest2_five_prime_exon_coding_region.java:114:  
>>>> getMoby_part_of()
>>>> in
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>>> cannot
>>>> override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>> use
>>>> incompatible return type
>>>>     [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>     [javac] required:  
>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>> getMoby_part_of()
>>> {
>>>>     [javac]
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev




From gordonp at ucalgary.ca  Wed Mar 11 19:04:57 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 11 Mar 2009 13:04:57 -0600
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm4qprnnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>	<op.uqm4flhynbznux@mark.ubic.ubc.ca>	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
	<op.uqm4qprnnbznux@mark.ubic.ubc.ca>
Message-ID: <49B80B59.2010204@ucalgary.ca>

Mark,

Hopefully we can find to the time next week to purge it a bit...

Mark Wilkinson wrote:
> No need to feel bad!  This is *precisely* how Moby ontology curation 
> is supposed to work!  Objects that are not being used, or that have a 
> "better" object defined elsewhere in the ontology, should be deleted 
> by the author of the object, or by anyone who finds it.  This is the 
> Web 2.0 aspect of Moby that hasn't really been working well (probably 
> because everyone feels the same as you about deleting other people's 
> stuff...).  The API prevents you from deleting objects that *are* 
> being used, but that's the only security we guarantee in Moby.
>
> M
>
>
>
> On Wed, 11 Mar 2009 11:32:11 -0700, Edward Kawas 
> <edward.kawas at gmail.com> wrote:
>
>> I feel bad doing so, but ok. I will back up their definitions and 
>> then remove them.
>>
>> When I am done, I will let everyone know.
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org 
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
>> Sent: March-11-09 11:32 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>>
>> Eddie, if no service uses them, and if no object uses them, then we 
>> should
>> probably consider deleting them...  this is allowed by the API.
>>
>> M
>>
>>
>>
>> On Wed, 11 Mar 2009 11:21:08 -0700, Michael Gerlich
>> <MichaelGerlich at gmx.de> wrote:
>>
>>> Hi,
>>>
>>> those datatypes are neither mine nor do I use them.
>>> They are registered at some French site. I don't use any of these 
>>> SOTEST*
>>> datatypes.
>>> I just can't get a fresh Biomoby checkout "installed" correctly or
>>> generate
>>> Moses code for one of my services (using pre-defined datatypes like
>>> ArrayString and/or ArrayFloat or one my own datatypes like MSPeakRel,
>>> which
>>> is derived from Array and having unique field names ;) ).
>>>
>>> Is there a way to circumvent these SOTEST* datatypes when running Moses
>>> and/or install ant script?
>>>
>>> Kind regards,
>>> Michael
>>>
>>>
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Mark
>>> Wilkinson
>>> Gesendet: Mittwoch, 11. M?rz 2009 18:44
>>> An: Core developer announcements
>>> Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant
>>>
>>> I believe that the MOBY Central code is supposed to check that
>>> articlenames are unique... but it may be bugged!
>>>
>>> M
>>>
>>>
>>>
>>> On Wed, 11 Mar 2009 10:00:29 -0700, Edward Kawas 
>>> <edward.kawas at gmail.com>
>>> wrote:
>>>
>>>> I think that I may have figured it out.
>>>>
>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>>> that
>>>> the main problem is that the datatype has 2 has relationships. It has
>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>>> both
>>>> have the articlename 'has_quality'.
>>>>
>>>> I am sure that articlenames in Services have to be unique, but I can't
>>>> find
>>>> any documentation online saying that articlenames describing
>>>> relationships
>>>> in Datatypes have to be unique as well.
>>>>
>>>> So, if articlenames have to be unique, then the registry inadvertently
>>>> allowed the registration of datatypes without unique articlenames for
>>>> container relationships. Alternatively, if this is allowed, then a bug
>>>> was
>>>> discovered in MoSeS.
>>>>
>>>> Anyone have any insight into which one is the correct scenario?
>>>> Eddie
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>> Gerlich
>>>> Sent: March-11-09 4:14 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi Eddie,
>>>>
>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>
>>>> This problem also occurs when I run install from a fresh CVS checkout
>>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>>> only registered at Central registry, so they are fetched when Biomoby
>>>> fills its cache (retrieving datatypes).
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> What version of JAVA are you using? What registry are you generating
>>>>> these
>>>>> datatypes from?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eddie
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>>> Gerlich
>>>>> Sent: March-10-09 4:28 PM
>>>>> To: MOBY-dev at lists.open-bio.org
>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>> corresponding
>>>>> ant tasks, but after fetching all necessary libraries, the 
>>>>> compilation
>>>> fails
>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>
>>>>> I also encountered this behavior when I tried to run Moses Generator
>>>>> for
>>>> one
>>>>> of my services with an existing Biomoby instance on another machine.
>>>>> There
>>>>> the build also fails.
>>>>> I tested this on 3 different machines, including both Ubuntu and 
>>>>> XP os.
>>>> The
>>>>> error log is attached, taken from Dashboad.
>>>>>
>>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>
>>>>> Thanks in advance and regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Excerpt follows (100 error messages like this):
>>>>>
>>>>>
>>>>
>>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat 
>>>
>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>> override
>>>>> getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>> attempting to use incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>     [javac] required:
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>>
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element 
>>>
>>>>> cannot override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>> to
>>>>> use incompatible return type
>>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>     [javac]                              ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>> getMoby_has_quality()
>>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>> cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>> to
>>>>> use incompatible return type
>>>>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>     [javac]                              ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>> override
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>>> attempting to use incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>>> getMoby_has_quality()
>>>>> in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>>> incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>> cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>> to
>>>>> use incompatible return type
>>>>>     [javac] found   : 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>     [javac]                                 ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>> getMoby_part_of() in
>>>>>
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region 
>>>
>>>>> cannot override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>>> use
>>>>> incompatible return type
>>>>>     [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>     [javac] required: 
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>> {
>>>>>     [javac]                                             ^
>>>>>     [javac]
>>>>>
>>>>
>>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>>
>>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>>> getMoby_part_of()
>>>>> in
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>>>> cannot
>>>>> override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to
>>>>> use
>>>>> incompatible return type
>>>>>     [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>     [javac] required: 
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>     [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>> {
>>>>>     [javac]
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev


From markw at illuminae.com  Wed Mar 11 19:39:43 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 11 Mar 2009 12:39:43 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49B80B59.2010204@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>
	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>
	<49B79D06.5090208@ipb-halle.de>
	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<op.uqm163nqnbznux@mark.ubic.ubc.ca>
	<001e01c9a276$283878c0$78a96a40$@de>
	<op.uqm4flhynbznux@mark.ubic.ubc.ca>
	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>
	<op.uqm4qprnnbznux@mark.ubic.ubc.ca> <49B80B59.2010204@ucalgary.ca>
Message-ID: <op.uqm7khipnbznux@mark.ubic.ubc.ca>

Amen!


On Wed, 11 Mar 2009 12:04:57 -0700, Paul Gordon <gordonp at ucalgary.ca>  
wrote:

> Mark,
>
> Hopefully we can find to the time next week to purge it a bit...


From edward.kawas at gmail.com  Wed Mar 11 19:55:41 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 11 Mar 2009 12:55:41 -0700
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <op.uqm7khipnbznux@mark.ubic.ubc.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>	<op.uqm4flhynbznux@mark.ubic.ubc.ca>	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>	<op.uqm4qprnnbznux@mark.ubic.ubc.ca>
	<49B80B59.2010204@ucalgary.ca> <op.uqm7khipnbznux@mark.ubic.ubc.ca>
Message-ID: <49b81757.25578c0a.5a64.ffffa22a@mx.google.com>

Okay, I finally have removed all of the datatypes. I have a backup of them
all (1400 or so datatypes ...)

Dashboard seems to be happy again and MOSES generates everything
successfully.

Make sure to remove the files in the moby-live/Java/generated/ folder and
try again.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 12:40 PM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Amen!


On Wed, 11 Mar 2009 12:04:57 -0700, Paul Gordon <gordonp at ucalgary.ca>  
wrote:

> Mark,
>
> Hopefully we can find to the time next week to purge it a bit...
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From MichaelGerlich at gmx.de  Wed Mar 11 22:31:34 2009
From: MichaelGerlich at gmx.de (Michael Gerlich)
Date: Wed, 11 Mar 2009 23:31:34 +0100
Subject: [MOBY-dev] [moby] Re:  error installing Biomoby via ant
In-Reply-To: <49b81757.25578c0a.5a64.ffffa22a@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<op.uqm163nqnbznux@mark.ubic.ubc.ca>	<001e01c9a276$283878c0$78a96a40$@de>	<op.uqm4flhynbznux@mark.ubic.ubc.ca>	<49b803c4.1a36720a.27ca.ffff822e@mx.google.com>	<op.uqm4qprnnbznux@mark.ubic.ubc.ca>	<49B80B59.2010204@ucalgary.ca>
	<op.uqm7khipnbznux@mark.ubic.ubc.ca>
	<49b81757.25578c0a.5a64.ffffa22a@mx.google.com>
Message-ID: <000901c9a299$23095540$691bffc0$@de>

[Success] 
  [Success] Installation completed.
  [Success] 
  [Success] Thanks for any comments and suggestions
  [Success] (moby-l at biomoby.org or moby-dev at biomoby.org)
  [Success]   

Just what I wanted to see - thanks for your efforts ;-)

Greetings,
Michael


-----Urspr?ngliche Nachricht-----
Von: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] Im Auftrag von Edward Kawas
Gesendet: Mittwoch, 11. M?rz 2009 20:56
An: 'Core developer announcements'
Betreff: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Okay, I finally have removed all of the datatypes. I have a backup of them
all (1400 or so datatypes ...)

Dashboard seems to be happy again and MOSES generates everything
successfully.

Make sure to remove the files in the moby-live/Java/generated/ folder and
try again.

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Mark Wilkinson
Sent: March-11-09 12:40 PM
To: Core developer announcements
Subject: Re: [MOBY-dev] [moby] Re: error installing Biomoby via ant

Amen!


On Wed, 11 Mar 2009 12:04:57 -0700, Paul Gordon <gordonp at ucalgary.ca>  
wrote:

> Mark,
>
> Hopefully we can find to the time next week to purge it a bit...
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev




From Sebastien.Carrere at toulouse.inra.fr  Tue Mar 24 09:27:24 2009
From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Tue, 24 Mar 2009 10:27:24 +0100
Subject: [MOBY-dev] primitive datatype: Password
Message-ID: <49C8A77C.1010104@toulouse.inra.fr>

Bonjour a tous,

What do you think about setting a new primitive datatype "Password" in 
addition to "String", "Integer", "DateTime", "Float", "Boolean"?

We plan to use secondary inputs to control some web-services access 
(using login/password).
Defining such a primitive datatype for parameters could be usefull for 
web interface: we could deal with this kind of parameters as we do with 
password fields in HTML forms.

What is your point of view ?

Merci,

Sebastien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sebastien_Carrere.vcf
Type: text/x-vcard
Size: 387 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090324/b9443237/attachment-0002.vcf>

From dmitry.repchevski at bsc.es  Tue Mar 24 19:13:25 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 12:13:25 -0700
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <49C8A77C.1010104@toulouse.inra.fr>
References: <49C8A77C.1010104@toulouse.inra.fr>
Message-ID: <49C930D5.70402@bsc.es>

I think this is a bad idea...

Moby primitive types are exactly that - "primitive", no any hint of it's
usage is given.
More, since Moby uses XML as a serialization this is a subset of schema
datatype (or at least intended to be?).
Extending basic Moby datatypes is not that easy, because all the
packages must be updated to support it.
For months I've been promised by my colleagues to include "Binary" type
to be able to pass base64 directly...
http://lists.open-bio.org/pipermail/moby-dev/2008-November/005382.html

Best regards,

Dmitry





From srramirez at uma.es  Tue Mar 24 12:41:25 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Mar 2009 13:41:25 +0100
Subject: [MOBY-dev] WSDL parsing library
Message-ID: <49C8D4F5.10104@uma.es>

Hello to all the mobiers,

I'm doing a little experiment with WSDL and I have found some problems 
with the libraries for parsing it. I have tried wsdl4j, wsif and wooden.

Does anyone knows a good library for make this?

Thanks in advance.
Sergio.

-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 



From pieter.neerincx at gmail.com  Tue Mar 24 13:06:57 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Tue, 24 Mar 2009 14:06:57 +0100
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <49C8A77C.1010104@toulouse.inra.fr>
References: <49C8A77C.1010104@toulouse.inra.fr>
Message-ID: <203FDC18-6B4B-46D5-8CB2-493D769F576A@gmail.com>

Hi Sebastian,

Just a few comments/thoughts:

1. There is already a password datatype in the object ontology that  
you can use... It's not a primitive, but I don't see why it would have  
to be. It currently simply inherits from Object. Hence Password ISA  
Object. (There has been some discussion on wether or not to create  
more specialised objects without adding any children, but Password has  
been around for several years now...)

2. Secondaries are something different than Primitives. The Primitives  
are always (part of) primary inputs or outputs and the primitives are  
therefore part of the object ontology. Note that secondary inputs or  
outputs are not part of the object ontology. The secondaries do come  
in exactly the same flavors as the primitives: "String", "Integer",  
"DateTime", "Float", "Boolean". So I can understand the confusion...

Hence with what is currently available you can already use:
* A Password object as primary input.
* A String primitive with the articleName attribute password or  
something similar.
* A secondary input of type String with the articleName attribute  
password or something similar.

There are several services that use similar constructs. They all work  
just fine. The only problem is that there is no standardised mechanism  
for authentication in BioMoby, which is not so user friendly.... A  
standardised mechanism would be nice and having a password and  
optional login/accountname as primaries or secondaries makes sense to  
me. All we would have to do is agree on the object (for primaries) or  
type (for secondaries) and articleName for these.... Theoretically a  
secondary input is optional and a client should be able to leave it  
out. Most secured services will require a password though, so one can  
argue that passwords and logins must be primary inputs. I don't think  
it matters too much. As long as we standardise on something it would  
make it easier for clients to figure out how to do authentication.

There are several people who will probably suggest to handle logins  
and password on a different level. You can do it on the transport  
level, on the web server level, in the SOAP layer or you could use  
WSRF et al. Some of these would be theoretically more elegant, but  
they usually cause more overhead and more time to implement. Doing it  
in BioMoby ourselves is peanuts and gives us more control on how to do  
it: no external dependancies, libraries, etc. So I think handling  
authentication in BioMoby is the more pragmatic solution. My services  
use the Password object for several years now: it was easy to  
implement and works just fine :)

Cheers,

Pi


On 24?Mar?2009, at 10:27 AM, Sebastien Carrere wrote:

> Bonjour a tous,
>
> What do you think about setting a new primitive datatype "Password"  
> in addition to "String", "Integer", "DateTime", "Float", "Boolean"?
>
> We plan to use secondary inputs to control some web-services access  
> (using login/password).
> Defining such a primitive datatype for parameters could be usefull  
> for web interface: we could deal with this kind of parameters as we  
> do with password fields in HTML forms.
>
> What is your point of view ?
>
> Merci,
>
> Sebastien
> <Sebastien_Carrere.vcf>_______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone: +31 (0)6-143 66 783
email: pieter.neerincx at gmail.com
skype: pieter.online
------------------------------------------------------------




From dmitry.repchevski at bsc.es  Tue Mar 24 21:48:17 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 14:48:17 -0700
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C8D4F5.10104@uma.es>
References: <49C8D4F5.10104@uma.es>
Message-ID: <49C95521.10300@bsc.es>

Hello Sergio!

I use wsdl4j. It just fine for me.
Do you have any specific question?

Dmitry


From Sebastien.Carrere at toulouse.inra.fr  Tue Mar 24 14:27:31 2009
From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere)
Date: Tue, 24 Mar 2009 15:27:31 +0100
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <203FDC18-6B4B-46D5-8CB2-493D769F576A@gmail.com>
References: <49C8A77C.1010104@toulouse.inra.fr>
	<203FDC18-6B4B-46D5-8CB2-493D769F576A@gmail.com>
Message-ID: <49C8EDD3.1070208@toulouse.inra.fr>

Hi Pieter,


> 1. There is already a password datatype in the object ontology that 
> you can use... It's not a primitive, but I don't see why it would have 
> to be. It currently simply inherits from Object. Hence Password ISA 
> Object. (There has been some discussion on wether or not to create 
> more specialised objects without adding any children, but Password has 
> been around for several years now...)
Yes, I've seen this existing object, but it can not be used as a 
Secondary input type (because secondary only accept primitive as far as 
I know)
>
> 2. Secondaries are something different than Primitives. The Primitives 
> are always (part of) primary inputs or outputs and the primitives are 
> therefore part of the object ontology. Note that secondary inputs or 
> outputs are not part of the object ontology. The secondaries do come 
> in exactly the same flavors as the primitives: "String", "Integer", 
> "DateTime", "Float", "Boolean". So I can understand the confusion...
>
> Hence with what is currently available you can already use:
> * A Password object as primary input.
> * A String primitive with the articleName attribute password or 
> something similar.
> * A secondary input of type String with the articleName attribute 
> password or something similar.
This last point is exactly what I plan to do, but we have to use the 
same articleName (password is a good one) to be able to identify such 
particular parameters.

>
> There are several services that use similar constructs. They all work 
> just fine. The only problem is that there is no standardised mechanism 
> for authentication in BioMoby, which is not so user friendly.... A 
> standardised mechanism would be nice and having a password and 
> optional login/accountname as primaries or secondaries makes sense to 
> me. All we would have to do is agree on the object (for primaries) or 
> type (for secondaries) and articleName for these.... Theoretically a 
> secondary input is optional and a client should be able to leave it 
> out. Most secured services will require a password though, so one can 
> argue that passwords and logins must be primary inputs. I don't think 
> it matters too much. As long as we standardise on something it would 
> make it easier for clients to figure out how to do authentication.
>
> There are several people who will probably suggest to handle logins 
> and password on a different level. You can do it on the transport 
> level, on the web server level, in the SOAP layer or you could use 
> WSRF et al. Some of these would be theoretically more elegant, but 
> they usually cause more overhead and more time to implement. Doing it 
> in BioMoby ourselves is peanuts and gives us more control on how to do 
> it: no external dependancies, libraries, etc. So I think handling 
> authentication in BioMoby is the more pragmatic solution. My services 
> use the Password object for several years now: it was easy to 
> implement and works just fine :)
I totally agree with your point of view, becasue in our case, 
web-services are just wrapped programs that we use also as cli and as 
Mobyle services. That's why we have to deal authentication directly at 
the web-service/script level and not at the transport level.
And as you say, using secondary inputs seems the best way to allow 
public-users (non authetified ones) to access limited web-services and 
registered-users to access full ones.

So I'm going to use Secondary inputs of type String with the articleName 
attribute password.


Sebastien




>> Bonjour a tous,
>>
>> What do you think about setting a new primitive datatype "Password" 
>> in addition to "String", "Integer", "DateTime", "Float", "Boolean"?
>>
>> We plan to use secondary inputs to control some web-services access 
>> (using login/password).
>> Defining such a primitive datatype for parameters could be usefull 
>> for web interface: we could deal with this kind of parameters as we 
>> do with password fields in HTML forms.
>>
>> What is your point of view ?
>>
>> Merci,
>>
>> Sebastien
>> <Sebastien_Carrere.vcf>_______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone: +31 (0)6-143 66 783
> email: pieter.neerincx at gmail.com
> skype: pieter.online
> ------------------------------------------------------------
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sebastien_Carrere.vcf
Type: text/x-vcard
Size: 387 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090324/3520afce/attachment-0002.vcf>

From srramirez at uma.es  Tue Mar 24 14:31:29 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Mar 2009 15:31:29 +0100
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C95521.10300@bsc.es>
References: <49C8D4F5.10104@uma.es> <49C95521.10300@bsc.es>
Message-ID: <49C8EEC1.8050707@uma.es>

Thanks for  the answer Dmitry.

With wsdl4j my problem was that I couldn't access the datatypes of 
service parameters, it always return me null.

Dmitry Repchevsky wrote:
> Hello Sergio!
>
> I use wsdl4j. It just fine for me.
> Do you have any specific question?
>
> Dmitry
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>


-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 



From dmitry.repchevski at bsc.es  Tue Mar 24 22:49:11 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 15:49:11 -0700
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C8EEC1.8050707@uma.es>
References: <49C8EEC1.8050707@uma.es>
Message-ID: <49C96367.7070300@bsc.es>

I an not sure about RPC-encoded...

WSDLParser parser
List<QName> paramz  = parser.getInputParameters(service, port, 
operation); // service, port, operation are QName

The problem is that after getting the name (in "document" type) you have 
to parss XML Schema...

I started an utility to execute any WSDL service (something Taverna 
fails to do). The idea is the same - given WSDL obtain services, schemas 
and be able to EDIT an input to it...
Unfortunately I had to switch to another project and have no workable 
code now... But sure I will finish it one day :-)
I need it to be able to execute my Nemus services:
http://inb.bsc.es/documents/java/nemus/index.html

Cheers,

Dmitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WSDLExecutor.png
Type: image/png
Size: 25832 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090324/35ba3a01/attachment-0002.png>

From srramirez at uma.es  Tue Mar 24 15:06:25 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Mar 2009 16:06:25 +0100
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C96367.7070300@bsc.es>
References: <49C8EEC1.8050707@uma.es> <49C96367.7070300@bsc.es>
Message-ID: <49C8F6F1.1030400@uma.es>

Dear Dmitry

Thank you very much for your help, I think maybe we can share 
experiences. Moving to wsif I can parse the datatypes of an wsdl 
document. Is very nice you can check the if it is an array or not, the 
component  elements and other things.

It works for me for a set of wsdl files, but when I switch to another 
set simply it doesn't give me any attribute.

So that is my problem.

Dmitry Repchevsky wrote:
> I an not sure about RPC-encoded...
>
> WSDLParser parser
> List<QName> paramz  = parser.getInputParameters(service, port, 
> operation); // service, port, operation are QName
>
> The problem is that after getting the name (in "document" type) you 
> have to parss XML Schema...
>
> I started an utility to execute any WSDL service (something Taverna 
> fails to do). The idea is the same - given WSDL obtain services, 
> schemas and be able to EDIT an input to it...
> Unfortunately I had to switch to another project and have no workable 
> code now... But sure I will finish it one day :-)
> I need it to be able to execute my Nemus services:
> http://inb.bsc.es/documents/java/nemus/index.html
>
> Cheers,
>
> Dmitry
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>   


-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 



From soiland-reyes at cs.manchester.ac.uk  Tue Mar 24 16:20:52 2009
From: soiland-reyes at cs.manchester.ac.uk (Stian Soiland-Reyes)
Date: Tue, 24 Mar 2009 16:20:52 +0000
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C96367.7070300@bsc.es>
References: <49C8EEC1.8050707@uma.es> <49C96367.7070300@bsc.es>
Message-ID: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>

2009/3/24 Dmitry Repchevsky <dmitry.repchevski at bsc.es>:

> I started an utility to execute any WSDL service (something Taverna fails to
> do). The idea is the same - given WSDL obtain services, schemas and be able

Hi!

It would be great if you could report to the taverna-hackers list [1]
any WSDL Taverna fails to understand or invoke. We have as a goal that
Taverna should be able to invoke any WSDL-service.

If the service in question is not publicly available, you could try to
attach the WSDL and any schema files (and example workflows that
fails) to your message.


[1] http://www.mygrid.org.uk/tools/taverna/taverna-mailing-lists/



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester


From dmitry.repchevski at bsc.es  Wed Mar 25 00:47:13 2009
From: dmitry.repchevski at bsc.es (Dmitry Repchevsky)
Date: Tue, 24 Mar 2009 17:47:13 -0700
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>
References: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>
Message-ID: <49C97F11.3010102@bsc.es>

Hello Stian!

I read in taverna mailing list that it has problems with "bare" services 
(and it was so few months ago, I checked). Also it has problem with 
complex schema (inheritance).

Try
http://inb.bsc.es/gn6/proxy/runPhylipKitsch?wsdl

I developed a proxy to all our Moby services representing them as WSDL + 
Schema

I would be happy to be able to use them in a workflow.
Also I think the way Taverna parses XML input/output (splitters) is far 
away from the best one...

Dmitry


From soiland-reyes at cs.manchester.ac.uk  Wed Mar 25 08:23:08 2009
From: soiland-reyes at cs.manchester.ac.uk (Stian Soiland-Reyes)
Date: Wed, 25 Mar 2009 08:23:08 +0000
Subject: [MOBY-dev] WSDL parsing library
In-Reply-To: <49C97F11.3010102@bsc.es>
References: <a20e6fb10903240920l6ff9babam6e05f43b91889470@mail.gmail.com>
	<49C97F11.3010102@bsc.es>
Message-ID: <a20e6fb10903250123t6bfd2f8cs4b8153242c0c719c@mail.gmail.com>

On Wed, Mar 25, 2009 at 00:47, Dmitry Repchevsky
<dmitry.repchevski at bsc.es> wrote:
> Hello Stian!
>
> I read in taverna mailing list that it has problems with "bare" services
> (and it was so few months ago, I checked). Also it has problem with complex
> schema (inheritance).

I haven't heard about this "bare" problem.. I can't see it in on our
mailing list archives or bug tracker..


> Try
> http://inb.bsc.es/gn6/proxy/runPhylipKitsch?wsdl

What would be an example input and output for that service..?


I agree that for some quite complex types you do get a lot of XML
splitters - this comes down to XML splitters working on the level of
one per element/type.

That's something we want to improve by hiding the splitters and doing
instead some kind of port selection based on the schema, from within a
configuration dialogue of the WSDL activity. [1]

http://www.mygrid.org.uk/dev/issues/browse/TAV-510


If you're on the taverna-hackers, let's continue the thread there! :-)

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester


From edward.kawas at gmail.com  Wed Mar 25 17:29:44 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Wed, 25 Mar 2009 10:29:44 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49B7F2BF.2060801@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
Message-ID: <49ca6a0a.02578c0a.295c.13de@mx.google.com>

Based on what Paul has said, is it true that the datatypes
(GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?

Thanks,

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: March-11-09 10:20 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

I can confirm that member articleNames must be unique.  Otherwise there 
would be no way to distinguish two HAS and a HAS-A instance.

Edward Kawas wrote:
> I think that I may have figured it out.
>
> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
that
> the main problem is that the datatype has 2 has relationships. It has
> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
both
> have the articlename 'has_quality'.
>
> I am sure that articlenames in Services have to be unique, but I can't
find
> any documentation online saying that articlenames describing relationships
> in Datatypes have to be unique as well.
>
> So, if articlenames have to be unique, then the registry inadvertently
> allowed the registration of datatypes without unique articlenames for
> container relationships. Alternatively, if this is allowed, then a bug was
> discovered in MoSeS.
>
> Anyone have any insight into which one is the correct scenario?
>  
> Eddie
>
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
> Sent: March-11-09 4:14 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> Hi Eddie,
>
> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour 
> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6 
> generated services and axis 1.4 and Tomcat5.5).
>
> This problem also occurs when I run install from a fresh CVS checkout 
> (including a fresh Biomoby cache directory). All SOTEST* datatypes are 
> only registered at Central registry, so they are fetched when Biomoby 
> fills its cache (retrieving datatypes).
>
> Regards,
>
> Michael
>
>   
>> Hi Michael,
>>
>> What version of JAVA are you using? What registry are you generating
these
>> datatypes from?
>>
>> Thanks,
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael Gerlich
>> Sent: March-10-09 4:28 PM
>> To: MOBY-dev at lists.open-bio.org
>> Subject: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi all,
>>
>> I checked out Biomoby from CVS and tried to install it via the
>>     
> corresponding
>   
>> ant tasks, but after fetching all necessary libraries, the compilation
>>     
> fails
>   
>> with a lot of error messages regarding datatypes SOTEST*.
>>
>> I also encountered this behavior when I tried to run Moses Generator for
>>     
> one
>   
>> of my services with an existing Biomoby instance on another machine.
There
>> the build also fails. 
>> I tested this on 3 different machines, including both Ubuntu and XP os.
>>     
> The
>   
>> error log is attached, taken from Dashboad.
>>
>> Does anyone encounter similar problems? Should I try cleaning Maven
>> repository, Biomoby cache and/or new Eclipse workspace?
>>
>> Thanks in advance and regards,
>> Michael
>>
>>
>> Excerpt follows (100 error messages like this):
>>
>>
>>     
>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>   
>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>     
> override
>   
>> getMoby_Parent() in org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>     [javac] required:
>>     
> org.biomoby.shared.datatypes.SOTest2_engineered_region
>   
>>     [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>> getMoby_has_quality() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>   
>> cannot override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_foreign_transposable_element.java:112:
getMoby_has_quality()
>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>     [javac]                              ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_fusion_gene.java:122: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>     
> override
>   
>> getMoby_has_quality() in
org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>> attempting to use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_rescue_region.java:120: getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>> incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_engineered_transposable_element.java:121:
>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>     
> cannot
>   
>> override getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; attempting
to
>> use incompatible return type
>>     [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>     [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>     [javac]                                 ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>> getMoby_part_of() in
>>
>>     
>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>   
>> cannot override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                                             ^
>>     [javac]
>>
>>     
>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>   
>> types/SOTest2_five_prime_exon_coding_region.java:114: getMoby_part_of()
in
>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region cannot
>> override getMoby_part_of() in
>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting to use
>> incompatible return type
>>     [javac] found   :
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>     [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>     [javac]     public SOTest2_five_prime_coding_exon[] getMoby_part_of()
>>     
> {
>   
>>     [javac]                            
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>   
>>     
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From pieter.neerincx at gmail.com  Wed Mar 25 23:45:09 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Thu, 26 Mar 2009 00:45:09 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49ca6a0a.02578c0a.295c.13de@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>
	<49B7F2BF.2060801@ucalgary.ca>
	<49ca6a0a.02578c0a.295c.13de@mx.google.com>
Message-ID: <6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>

Hi,

If I remember correctly for datatypes it's the combination of the  
object's name and articleName attribute value that must be unique. As  
long as the combi is unique you can distinguish two HAS and a HAS-A  
instance. Therefore if an object has multiple relationships involving  
child element of the same type a unique articleName attribute is  
mandatory but otherwise articleName attributes were optional. In  
addition articleNames in service inputs or outputs were mandatory and  
quite some time ago articleNames became also mandatory for primitives  
no matter whether there was only one relationship involving a certain  
type of primitive or whether there were more.

So AFAIK the GCP_* objects mentioned below are correctly registered  
according to the current specs, but to keep things simple it wouldn't  
hurt to make articleName attributes always mandatory. That would  
render quite some currently used objects invalid though...

Cheers,

Pi

On 25 Mar 2009, at 18:29, Edward Kawas wrote:

> Based on what Paul has said, is it true that the datatypes
> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>
> Thanks,
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: March-11-09 10:20 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> I can confirm that member articleNames must be unique.  Otherwise  
> there
> would be no way to distinguish two HAS and a HAS-A instance.
>
> Edward Kawas wrote:
>> I think that I may have figured it out.
>>
>> Using the datatype SOTest2_validated_cDNA_clone as an example, I  
>> think
> that
>> the main problem is that the datatype has 2 has relationships. It has
>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that  
>> they
> both
>> have the articlename 'has_quality'.
>>
>> I am sure that articlenames in Services have to be unique, but I  
>> can't
> find
>> any documentation online saying that articlenames describing  
>> relationships
>> in Datatypes have to be unique as well.
>>
>> So, if articlenames have to be unique, then the registry  
>> inadvertently
>> allowed the registration of datatypes without unique articlenames for
>> container relationships. Alternatively, if this is allowed, then a  
>> bug was
>> discovered in MoSeS.
>>
>> Anyone have any insight into which one is the correct scenario?
>>
>> Eddie
>>
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>> Gerlich
>> Sent: March-11-09 4:14 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> Hi Eddie,
>>
>> I'am using Suns JDK 1.5 Version 16. I also encountered this  
>> behavivour
>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>> generated services and axis 1.4 and Tomcat5.5).
>>
>> This problem also occurs when I run install from a fresh CVS checkout
>> (including a fresh Biomoby cache directory). All SOTEST* datatypes  
>> are
>> only registered at Central registry, so they are fetched when Biomoby
>> fills its cache (retrieving datatypes).
>>
>> Regards,
>>
>> Michael
>>
>>
>>> Hi Michael,
>>>
>>> What version of JAVA are you using? What registry are you generating
> these
>>> datatypes from?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael  
>>> Gerlich
>>> Sent: March-10-09 4:28 PM
>>> To: MOBY-dev at lists.open-bio.org
>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi all,
>>>
>>> I checked out Biomoby from CVS and tried to install it via the
>>>
>> corresponding
>>
>>> ant tasks, but after fetching all necessary libraries, the  
>>> compilation
>>>
>> fails
>>
>>> with a lot of error messages regarding datatypes SOTEST*.
>>>
>>> I also encountered this behavior when I tried to run Moses  
>>> Generator for
>>>
>> one
>>
>>> of my services with an existing Biomoby instance on another machine.
> There
>>> the build also fails.
>>> I tested this on 3 different machines, including both Ubuntu and  
>>> XP os.
>>>
>> The
>>
>>> error log is attached, taken from Dashboad.
>>>
>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>
>>> Thanks in advance and regards,
>>> Michael
>>>
>>>
>>> Excerpt follows (100 error messages like this):
>>>
>>>
>>>
>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/datat
>>
>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>
>> override
>>
>>> getMoby_Parent() in  
>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>> attempting to use incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>    [javac] required:
>>>
>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>
>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>> getMoby_has_quality() in
>>>
>>>
>>
> org 
> .biomoby 
> .shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>
>>> cannot override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>> attempting
> to
>>> use incompatible return type
>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>    [javac]                              ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_foreign_transposable_element.java:112:
> getMoby_has_quality()
>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>
>> cannot
>>
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>> attempting
> to
>>> use incompatible return type
>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>    [javac]                              ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_fusion_gene.java:122:  
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>
>> override
>>
>>> getMoby_has_quality() in
> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>> attempting to use incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_rescue_region.java:120:  
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to  
>>> use
>>> incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_engineered_transposable_element.java:121:
>>> getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>
>> cannot
>>
>>> override getMoby_has_quality() in
>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>> attempting
> to
>>> use incompatible return type
>>>    [javac] found   :  
>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>    [javac]                                 ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>> getMoby_part_of() in
>>>
>>>
>>
> org 
> .biomoby 
> .shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>
>>> cannot override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting  
>>> to use
>>> incompatible return type
>>>    [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>    [javac] required:  
>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>    [javac]     public SOTest2_five_prime_coding_exon[]  
>>> getMoby_part_of()
>>>
>> {
>>
>>>    [javac]                                             ^
>>>    [javac]
>>>
>>>
>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
> shared/data
>>
>>> types/SOTest2_five_prime_exon_coding_region.java:114:  
>>> getMoby_part_of()
> in
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>>> cannot
>>> override getMoby_part_of() in
>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting  
>>> to use
>>> incompatible return type
>>>    [javac] found   :
>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>    [javac] required:  
>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>    [javac]     public SOTest2_five_prime_coding_exon[]  
>>> getMoby_part_of()
>>>
>> {
>>
>>>    [javac]
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------





From gordonp at ucalgary.ca  Thu Mar 26 14:31:02 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu, 26 Mar 2009 08:31:02 -0600
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>
	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>
Message-ID: <49CB91A6.4030601@ucalgary.ca>

As there is no unique place to put documentation for the purpose or 
usage of a member other than its articleName, I'd suggest that the 
articleName be mandatory, if only for the purpose of succinctly 
describing the relationship between it and the container class.

Pieter Neerincx wrote:
> Hi,
>
> If I remember correctly for datatypes it's the combination of the 
> object's name and articleName attribute value that must be unique. As 
> long as the combi is unique you can distinguish two HAS and a HAS-A 
> instance. Therefore if an object has multiple relationships involving 
> child element of the same type a unique articleName attribute is 
> mandatory but otherwise articleName attributes were optional. In 
> addition articleNames in service inputs or outputs were mandatory and 
> quite some time ago articleNames became also mandatory for primitives 
> no matter whether there was only one relationship involving a certain 
> type of primitive or whether there were more.
>
> So AFAIK the GCP_* objects mentioned below are correctly registered 
> according to the current specs, but to keep things simple it wouldn't 
> hurt to make articleName attributes always mandatory. That would 
> render quite some currently used objects invalid though...
>
> Cheers,
>
> Pi
>
> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>
>> Based on what Paul has said, is it true that the datatypes
>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: March-11-09 10:20 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> I can confirm that member articleNames must be unique.  Otherwise there
>> would be no way to distinguish two HAS and a HAS-A instance.
>>
>> Edward Kawas wrote:
>>> I think that I may have figured it out.
>>>
>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>>> the main problem is that the datatype has 2 has relationships. It has
>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>>> have the articlename 'has_quality'.
>>>
>>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>>> any documentation online saying that articlenames describing 
>>> relationships
>>> in Datatypes have to be unique as well.
>>>
>>> So, if articlenames have to be unique, then the registry inadvertently
>>> allowed the registration of datatypes without unique articlenames for
>>> container relationships. Alternatively, if this is allowed, then a 
>>> bug was
>>> discovered in MoSeS.
>>>
>>> Anyone have any insight into which one is the correct scenario?
>>>
>>> Eddie
>>>
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>> Gerlich
>>> Sent: March-11-09 4:14 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi Eddie,
>>>
>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>> generated services and axis 1.4 and Tomcat5.5).
>>>
>>> This problem also occurs when I run install from a fresh CVS checkout
>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>> only registered at Central registry, so they are fetched when Biomoby
>>> fills its cache (retrieving datatypes).
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> What version of JAVA are you using? What registry are you generating
>> these
>>>> datatypes from?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>> Gerlich
>>>> Sent: March-10-09 4:28 PM
>>>> To: MOBY-dev at lists.open-bio.org
>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi all,
>>>>
>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>
>>> corresponding
>>>
>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>
>>> fails
>>>
>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>
>>>> I also encountered this behavior when I tried to run Moses 
>>>> Generator for
>>>>
>>> one
>>>
>>>> of my services with an existing Biomoby instance on another machine.
>> There
>>>> the build also fails.
>>>> I tested this on 3 different machines, including both Ubuntu and XP 
>>>> os.
>>>>
>>> The
>>>
>>>> error log is attached, taken from Dashboad.
>>>>
>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>
>>>> Thanks in advance and regards,
>>>> Michael
>>>>
>>>>
>>>> Excerpt follows (100 error messages like this):
>>>>
>>>>
>>>>
>>>
>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat 
>>
>>>
>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_Parent() in 
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>    [javac] required:
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>
>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>>
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element 
>>
>>>
>>>> cannot override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_foreign_transposable_element.java:112:
>> getMoby_has_quality()
>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>> incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>> getMoby_part_of() in
>>>>
>>>>
>>>
>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region 
>>
>>>
>>>> cannot override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]                                             ^
>>>>    [javac]
>>>>
>>>>
>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data 
>>
>>>
>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>> getMoby_part_of()
>> in
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region 
>>>> cannot
>>>> override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone:  +31 (0)317-483 060
> mobile: +31 (0)6-143 66 783
> e-mail: pieter.neerincx at gmail.com
> skype:  pieter.online
> -------------------------------------------------------------
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>


From edward.kawas at gmail.com  Thu Mar 26 15:00:41 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Thu, 26 Mar 2009 08:00:41 -0700
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49CB91A6.4030601@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>
	<49CB91A6.4030601@ucalgary.ca>
Message-ID: <49cb989d.15528c0a.1739.69c0@mx.google.com>

I thought that the articlename was supposed to be mandatory... anyways, the
2 services that I mentioned seem to be the only 2 incorrect datatypes. I
created a patch for the registry, but before I committed it, I wanted to
check that I had the general idea down.

The patch works like so:

User X is registering a datatype. We take all of the direct HAS/HASA
articlenames and then traverse the ISA hierarchy towards the root node
ensuring that the articlenames are not used further up the tree.

This is how I found those 2 datatypes that I mentioned previously. I tested
my patch against all datatypes in our ontology.

If everyone is happy with this, I will commit the patch and update the
documentation.

Thanks,

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: March-26-09 7:31 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] error installing Biomoby via ant

As there is no unique place to put documentation for the purpose or 
usage of a member other than its articleName, I'd suggest that the 
articleName be mandatory, if only for the purpose of succinctly 
describing the relationship between it and the container class.

Pieter Neerincx wrote:
> Hi,
>
> If I remember correctly for datatypes it's the combination of the 
> object's name and articleName attribute value that must be unique. As 
> long as the combi is unique you can distinguish two HAS and a HAS-A 
> instance. Therefore if an object has multiple relationships involving 
> child element of the same type a unique articleName attribute is 
> mandatory but otherwise articleName attributes were optional. In 
> addition articleNames in service inputs or outputs were mandatory and 
> quite some time ago articleNames became also mandatory for primitives 
> no matter whether there was only one relationship involving a certain 
> type of primitive or whether there were more.
>
> So AFAIK the GCP_* objects mentioned below are correctly registered 
> according to the current specs, but to keep things simple it wouldn't 
> hurt to make articleName attributes always mandatory. That would 
> render quite some currently used objects invalid though...
>
> Cheers,
>
> Pi
>
> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>
>> Based on what Paul has said, is it true that the datatypes
>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: March-11-09 10:20 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> I can confirm that member articleNames must be unique.  Otherwise there
>> would be no way to distinguish two HAS and a HAS-A instance.
>>
>> Edward Kawas wrote:
>>> I think that I may have figured it out.
>>>
>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>> that
>>> the main problem is that the datatype has 2 has relationships. It has
>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>> both
>>> have the articlename 'has_quality'.
>>>
>>> I am sure that articlenames in Services have to be unique, but I can't
>> find
>>> any documentation online saying that articlenames describing 
>>> relationships
>>> in Datatypes have to be unique as well.
>>>
>>> So, if articlenames have to be unique, then the registry inadvertently
>>> allowed the registration of datatypes without unique articlenames for
>>> container relationships. Alternatively, if this is allowed, then a 
>>> bug was
>>> discovered in MoSeS.
>>>
>>> Anyone have any insight into which one is the correct scenario?
>>>
>>> Eddie
>>>
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>> Gerlich
>>> Sent: March-11-09 4:14 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> Hi Eddie,
>>>
>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>> generated services and axis 1.4 and Tomcat5.5).
>>>
>>> This problem also occurs when I run install from a fresh CVS checkout
>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>> only registered at Central registry, so they are fetched when Biomoby
>>> fills its cache (retrieving datatypes).
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> What version of JAVA are you using? What registry are you generating
>> these
>>>> datatypes from?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>> Gerlich
>>>> Sent: March-10-09 4:28 PM
>>>> To: MOBY-dev at lists.open-bio.org
>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi all,
>>>>
>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>
>>> corresponding
>>>
>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>
>>> fails
>>>
>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>
>>>> I also encountered this behavior when I tried to run Moses 
>>>> Generator for
>>>>
>>> one
>>>
>>>> of my services with an existing Biomoby instance on another machine.
>> There
>>>> the build also fails.
>>>> I tested this on 3 different machines, including both Ubuntu and XP 
>>>> os.
>>>>
>>> The
>>>
>>>> error log is attached, taken from Dashboad.
>>>>
>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>
>>>> Thanks in advance and regards,
>>>> Michael
>>>>
>>>>
>>>> Excerpt follows (100 error messages like this):
>>>>
>>>>
>>>>
>>>
>>
home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat

>>
>>>
>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_Parent() in 
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>    [javac] required:
>>>>
>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>
>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>>
>>>>
>>>
>>
org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element

>>
>>>
>>>> cannot override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_foreign_transposable_element.java:112:
>> getMoby_has_quality()
>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>    [javac]                              ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>
>>> override
>>>
>>>> getMoby_has_quality() in
>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>> attempting to use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>> incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>> getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>
>>> cannot
>>>
>>>> override getMoby_has_quality() in
>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>> attempting
>> to
>>>> use incompatible return type
>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>    [javac]                                 ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>> getMoby_part_of() in
>>>>
>>>>
>>>
>>
org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region

>>
>>>
>>>> cannot override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]                                             ^
>>>>    [javac]
>>>>
>>>>
>>>
>>
/home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data

>>
>>>
>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>> getMoby_part_of()
>> in
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region 
>>>> cannot
>>>> override getMoby_part_of() in
>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>> to use
>>>> incompatible return type
>>>>    [javac] found   :
>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>> getMoby_part_of()
>>>>
>>> {
>>>
>>>>    [javac]
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone:  +31 (0)317-483 060
> mobile: +31 (0)6-143 66 783
> e-mail: pieter.neerincx at gmail.com
> skype:  pieter.online
> -------------------------------------------------------------
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From gordonp at ucalgary.ca  Thu Mar 26 15:07:09 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Thu, 26 Mar 2009 09:07:09 -0600
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49cb989d.15528c0a.1739.69c0@mx.google.com>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>	<49CB91A6.4030601@ucalgary.ca>
	<49cb989d.15528c0a.1739.69c0@mx.google.com>
Message-ID: <49CB9A1D.7040404@ucalgary.ca>

Sounds good to me.  If the docs don't say articleName is mandatory, that 
was an error of omission on our part...

Edward Kawas wrote:
> I thought that the articlename was supposed to be mandatory... anyways, the
> 2 services that I mentioned seem to be the only 2 incorrect datatypes. I
> created a patch for the registry, but before I committed it, I wanted to
> check that I had the general idea down.
>
> The patch works like so:
>
> User X is registering a datatype. We take all of the direct HAS/HASA
> articlenames and then traverse the ISA hierarchy towards the root node
> ensuring that the articlenames are not used further up the tree.
>
> This is how I found those 2 datatypes that I mentioned previously. I tested
> my patch against all datatypes in our ontology.
>
> If everyone is happy with this, I will commit the patch and update the
> documentation.
>
> Thanks,
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: March-26-09 7:31 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> As there is no unique place to put documentation for the purpose or 
> usage of a member other than its articleName, I'd suggest that the 
> articleName be mandatory, if only for the purpose of succinctly 
> describing the relationship between it and the container class.
>
> Pieter Neerincx wrote:
>   
>> Hi,
>>
>> If I remember correctly for datatypes it's the combination of the 
>> object's name and articleName attribute value that must be unique. As 
>> long as the combi is unique you can distinguish two HAS and a HAS-A 
>> instance. Therefore if an object has multiple relationships involving 
>> child element of the same type a unique articleName attribute is 
>> mandatory but otherwise articleName attributes were optional. In 
>> addition articleNames in service inputs or outputs were mandatory and 
>> quite some time ago articleNames became also mandatory for primitives 
>> no matter whether there was only one relationship involving a certain 
>> type of primitive or whether there were more.
>>
>> So AFAIK the GCP_* objects mentioned below are correctly registered 
>> according to the current specs, but to keep things simple it wouldn't 
>> hurt to make articleName attributes always mandatory. That would 
>> render quite some currently used objects invalid though...
>>
>> Cheers,
>>
>> Pi
>>
>> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>>
>>     
>>> Based on what Paul has said, is it true that the datatypes
>>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: March-11-09 10:20 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> I can confirm that member articleNames must be unique.  Otherwise there
>>> would be no way to distinguish two HAS and a HAS-A instance.
>>>
>>> Edward Kawas wrote:
>>>       
>>>> I think that I may have figured it out.
>>>>
>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>>>         
>>> that
>>>       
>>>> the main problem is that the datatype has 2 has relationships. It has
>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>>>         
>>> both
>>>       
>>>> have the articlename 'has_quality'.
>>>>
>>>> I am sure that articlenames in Services have to be unique, but I can't
>>>>         
>>> find
>>>       
>>>> any documentation online saying that articlenames describing 
>>>> relationships
>>>> in Datatypes have to be unique as well.
>>>>
>>>> So, if articlenames have to be unique, then the registry inadvertently
>>>> allowed the registration of datatypes without unique articlenames for
>>>> container relationships. Alternatively, if this is allowed, then a 
>>>> bug was
>>>> discovered in MoSeS.
>>>>
>>>> Anyone have any insight into which one is the correct scenario?
>>>>
>>>> Eddie
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>> Gerlich
>>>> Sent: March-11-09 4:14 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi Eddie,
>>>>
>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>
>>>> This problem also occurs when I run install from a fresh CVS checkout
>>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>>> only registered at Central registry, so they are fetched when Biomoby
>>>> fills its cache (retrieving datatypes).
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>>         
>>>>> Hi Michael,
>>>>>
>>>>> What version of JAVA are you using? What registry are you generating
>>>>>           
>>> these
>>>       
>>>>> datatypes from?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eddie
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael 
>>>>> Gerlich
>>>>> Sent: March-10-09 4:28 PM
>>>>> To: MOBY-dev at lists.open-bio.org
>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>>
>>>>>           
>>>> corresponding
>>>>
>>>>         
>>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>>
>>>>>           
>>>> fails
>>>>
>>>>         
>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>
>>>>> I also encountered this behavior when I tried to run Moses 
>>>>> Generator for
>>>>>
>>>>>           
>>>> one
>>>>
>>>>         
>>>>> of my services with an existing Biomoby instance on another machine.
>>>>>           
>>> There
>>>       
>>>>> the build also fails.
>>>>> I tested this on 3 different machines, including both Ubuntu and XP 
>>>>> os.
>>>>>
>>>>>           
>>>> The
>>>>
>>>>         
>>>>> error log is attached, taken from Dashboad.
>>>>>
>>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>
>>>>> Thanks in advance and regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Excerpt follows (100 error messages like this):
>>>>>
>>>>>
>>>>>
>>>>>           
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>
>   
>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>>
>>>>>           
>>>> override
>>>>
>>>>         
>>>>> getMoby_Parent() in 
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>    [javac] required:
>>>>>
>>>>>           
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>
>>>>         
>>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>>
>>>>>
>>>>>           
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>
>   
>>>>> cannot override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>>           
>>> to
>>>       
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>>           
>>> getMoby_has_quality()
>>>       
>>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>>
>>>>>           
>>>> cannot
>>>>
>>>>         
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>>           
>>> to
>>>       
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_fusion_gene.java:122: 
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>>
>>>>>           
>>>> override
>>>>
>>>>         
>>>>> getMoby_has_quality() in
>>>>>           
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>       
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_rescue_region.java:120: 
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>>> incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>>
>>>>>           
>>>> cannot
>>>>
>>>>         
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element; 
>>>>> attempting
>>>>>           
>>> to
>>>       
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>> getMoby_part_of() in
>>>>>
>>>>>
>>>>>           
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>
>   
>>>>> cannot override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>>> getMoby_part_of()
>>>>>
>>>>>           
>>>> {
>>>>
>>>>         
>>>>>    [javac]                                             ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>           
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>   
>>>>> types/SOTest2_five_prime_exon_coding_region.java:114: 
>>>>> getMoby_part_of()
>>>>>           
>>> in
>>>       
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region 
>>>>> cannot
>>>>> override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting 
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[] 
>>>>> getMoby_part_of()
>>>>>
>>>>>           
>>>> {
>>>>
>>>>         
>>>>>    [javac]
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>
>>>>         
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>       
>> -------------------------------------------------------------
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>>
>> phone:  +31 (0)317-483 060
>> mobile: +31 (0)6-143 66 783
>> e-mail: pieter.neerincx at gmail.com
>> skype:  pieter.online
>> -------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   


From markw at illuminae.com  Thu Mar 26 15:25:33 2009
From: markw at illuminae.com (markw at illuminae.com)
Date: Thu, 26 Mar 2009 15:25:33 +0000
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49CB9A1D.7040404@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>	<49CB91A6.4030601@ucalgary.ca><49cb989d.15528c0a.1739.69c0@mx.google.com><49CB9A1D.7040404@ucalgary.ca>
Message-ID: <691129944-1238081155-cardhu_decombobulator_blackberry.rim.net-1674883723-@bxe1187.bisx.prod.on.blackberry>

Agree 100% - I'm surprised that it isn't in the docs (if it isn't... It certainly *used* to be, but the docs have been moved around and edited quite a bit over the years)

M


On the Road!

-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>

Date: Thu, 26 Mar 2009 09:07:09 
To: Core developer announcements<moby-dev at lists.open-bio.org>
Subject: Re: [MOBY-dev] error installing Biomoby via ant


Sounds good to me.  If the docs don't say articleName is mandatory, that
was an error of omission on our part...

Edward Kawas wrote:
> I thought that the articlename was supposed to be mandatory... anyways, the
> 2 services that I mentioned seem to be the only 2 incorrect datatypes. I
> created a patch for the registry, but before I committed it, I wanted to
> check that I had the general idea down.
>
> The patch works like so:
>
> User X is registering a datatype. We take all of the direct HAS/HASA
> articlenames and then traverse the ISA hierarchy towards the root node
> ensuring that the articlenames are not used further up the tree.
>
> This is how I found those 2 datatypes that I mentioned previously. I tested
> my patch against all datatypes in our ontology.
>
> If everyone is happy with this, I will commit the patch and update the
> documentation.
>
> Thanks,
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: March-26-09 7:31 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>
> As there is no unique place to put documentation for the purpose or
> usage of a member other than its articleName, I'd suggest that the
> articleName be mandatory, if only for the purpose of succinctly
> describing the relationship between it and the container class.
>
> Pieter Neerincx wrote:
>
>> Hi,
>>
>> If I remember correctly for datatypes it's the combination of the
>> object's name and articleName attribute value that must be unique. As
>> long as the combi is unique you can distinguish two HAS and a HAS-A
>> instance. Therefore if an object has multiple relationships involving
>> child element of the same type a unique articleName attribute is
>> mandatory but otherwise articleName attributes were optional. In
>> addition articleNames in service inputs or outputs were mandatory and
>> quite some time ago articleNames became also mandatory for primitives
>> no matter whether there was only one relationship involving a certain
>> type of primitive or whether there were more.
>>
>> So AFAIK the GCP_* objects mentioned below are correctly registered
>> according to the current specs, but to keep things simple it wouldn't
>> hurt to make articleName attributes always mandatory. That would
>> render quite some currently used objects invalid though...
>>
>> Cheers,
>>
>> Pi
>>
>> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>>
>>
>>> Based on what Paul has said, is it true that the datatypes
>>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly registered?
>>>
>>> Thanks,
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: March-11-09 10:20 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>
>>> I can confirm that member articleNames must be unique.  Otherwise there
>>> would be no way to distinguish two HAS and a HAS-A instance.
>>>
>>> Edward Kawas wrote:
>>>
>>>> I think that I may have figured it out.
>>>>
>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I think
>>>>
>>> that
>>>
>>>> the main problem is that the datatype has 2 has relationships. It has
>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is that they
>>>>
>>> both
>>>
>>>> have the articlename 'has_quality'.
>>>>
>>>> I am sure that articlenames in Services have to be unique, but I can't
>>>>
>>> find
>>>
>>>> any documentation online saying that articlenames describing
>>>> relationships
>>>> in Datatypes have to be unique as well.
>>>>
>>>> So, if articlenames have to be unique, then the registry inadvertently
>>>> allowed the registration of datatypes without unique articlenames for
>>>> container relationships. Alternatively, if this is allowed, then a
>>>> bug was
>>>> discovered in MoSeS.
>>>>
>>>> Anyone have any insight into which one is the correct scenario?
>>>>
>>>> Eddie
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>> Gerlich
>>>> Sent: March-11-09 4:14 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> Hi Eddie,
>>>>
>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this behavivour
>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>
>>>> This problem also occurs when I run install from a fresh CVS checkout
>>>> (including a fresh Biomoby cache directory). All SOTEST* datatypes are
>>>> only registered at Central registry, so they are fetched when Biomoby
>>>> fills its cache (retrieving datatypes).
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> What version of JAVA are you using? What registry are you generating
>>>>>
>>> these
>>>
>>>>> datatypes from?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eddie
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Michael
>>>>> Gerlich
>>>>> Sent: March-10-09 4:28 PM
>>>>> To: MOBY-dev at lists.open-bio.org
>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>>
>>>>>
>>>> corresponding
>>>>
>>>>
>>>>> ant tasks, but after fetching all necessary libraries, the compilation
>>>>>
>>>>>
>>>> fails
>>>>
>>>>
>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>
>>>>> I also encountered this behavior when I tried to run Moses
>>>>> Generator for
>>>>>
>>>>>
>>>> one
>>>>
>>>>
>>>>> of my services with an existing Biomoby instance on another machine.
>>>>>
>>> There
>>>
>>>>> the build also fails.
>>>>> I tested this on 3 different machines, including both Ubuntu and XP
>>>>> os.
>>>>>
>>>>>
>>>> The
>>>>
>>>>
>>>>> error log is attached, taken from Dashboad.
>>>>>
>>>>> Does anyone encounter similar problems? Should I try cleaning Maven
>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>
>>>>> Thanks in advance and regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Excerpt follows (100 error messages like this):
>>>>>
>>>>>
>>>>>
>>>>>
> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/datat
>
>
>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene cannot
>>>>>
>>>>>
>>>> override
>>>>
>>>>
>>>>> getMoby_Parent() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>    [javac] required:
>>>>>
>>>>>
>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>
>>>>
>>>>>    [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>>
>>>>>
>>>>>
> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_transposable_element
>
>
>>>>> cannot override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;
>>>>> attempting
>>>>>
>>> to
>>>
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>>
>>> getMoby_has_quality()
>>>
>>>>> in org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;
>>>>> attempting
>>>>>
>>> to
>>>
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>    [javac]                              ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_fusion_gene.java:122:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene cannot
>>>>>
>>>>>
>>>> override
>>>>
>>>>
>>>>> getMoby_has_quality() in
>>>>>
>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>
>>>>> attempting to use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_rescue_region.java:120:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region cannot
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting to use
>>>>> incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>> getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>>
>>>>>
>>>> cannot
>>>>
>>>>
>>>>> override getMoby_has_quality() in
>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;
>>>>> attempting
>>>>>
>>> to
>>>
>>>>> use incompatible return type
>>>>>    [javac] found   : org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>    [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>    [javac]                                 ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>> getMoby_part_of() in
>>>>>
>>>>>
>>>>>
> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>
>
>>>>> cannot override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>>>
>>>>>
>>>> {
>>>>
>>>>
>>>>>    [javac]                                             ^
>>>>>    [javac]
>>>>>
>>>>>
>>>>>
> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/shared/data
>
>
>>>>> types/SOTest2_five_prime_exon_coding_region.java:114:
>>>>> getMoby_part_of()
>>>>>
>>> in
>>>
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region
>>>>> cannot
>>>>> override getMoby_part_of() in
>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region; attempting
>>>>> to use
>>>>> incompatible return type
>>>>>    [javac] found   :
>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>    [javac] required: org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>    [javac]     public SOTest2_five_prime_coding_exon[]
>>>>> getMoby_part_of()
>>>>>
>>>>>
>>>> {
>>>>
>>>>
>>>>>    [javac]
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>> -------------------------------------------------------------
>> Wageningen University and Research centre (WUR)
>> Laboratory of Bioinformatics
>> Transitorium (building 312) room 1034
>>
>> Dreijenlaan 3
>> 6703 HA Wageningen
>> The Netherlands
>>
>> phone:  +31 (0)317-483 060
>> mobile: +31 (0)6-143 66 783
>> e-mail: pieter.neerincx at gmail.com
>> skype:  pieter.online
>> -------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From pieter.neerincx at gmail.com  Thu Mar 26 15:47:31 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Thu, 26 Mar 2009 16:47:31 +0100
Subject: [MOBY-dev] error installing Biomoby via ant
In-Reply-To: <49CB9A1D.7040404@ucalgary.ca>
References: <000001c9a1d7$ccf5a120$66e0e360$@de>	<49b70aac.1cbc720a.5945.ffffc6ac@mx.google.com>	<49B79D06.5090208@ipb-halle.de>	<49b7ee46.02578c0a.1260.ffff816d@mx.google.com>	<49B7F2BF.2060801@ucalgary.ca>	<49ca6a0a.02578c0a.295c.13de@mx.google.com>	<6A499280-C114-4A3A-8181-2720E1E66D51@gmail.com>	<49CB91A6.4030601@ucalgary.ca>
	<49cb989d.15528c0a.1739.69c0@mx.google.com>
	<49CB9A1D.7040404@ucalgary.ca>
Message-ID: <B9532ED4-462E-47EB-8FEF-A08DABEDAB0B@gmail.com>

Making the articleName attributes mandatory in all cases will also  
help to make MoSeS generated code more readable. If the optional  
articleName attributes are missing, MoSeS will generate some variables  
with "placeholder names". If you have more than one of those, things  
can get rather confusing. So you have my vote for making articleName  
attributes mandatory in all circumstances!

Cheers,

Pi

On 26 Mar 2009, at 16:07, Paul Gordon wrote:

> Sounds good to me.  If the docs don't say articleName is mandatory,  
> that was an error of omission on our part...
>
> Edward Kawas wrote:
>> I thought that the articlename was supposed to be mandatory...  
>> anyways, the
>> 2 services that I mentioned seem to be the only 2 incorrect  
>> datatypes. I
>> created a patch for the registry, but before I committed it, I  
>> wanted to
>> check that I had the general idea down.
>>
>> The patch works like so:
>>
>> User X is registering a datatype. We take all of the direct HAS/HASA
>> articlenames and then traverse the ISA hierarchy towards the root  
>> node
>> ensuring that the articlenames are not used further up the tree.
>>
>> This is how I found those 2 datatypes that I mentioned previously.  
>> I tested
>> my patch against all datatypes in our ontology.
>>
>> If everyone is happy with this, I will commit the patch and update  
>> the
>> documentation.
>>
>> Thanks,
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: March-26-09 7:31 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>
>> As there is no unique place to put documentation for the purpose or  
>> usage of a member other than its articleName, I'd suggest that the  
>> articleName be mandatory, if only for the purpose of succinctly  
>> describing the relationship between it and the container class.
>>
>> Pieter Neerincx wrote:
>>
>>> Hi,
>>>
>>> If I remember correctly for datatypes it's the combination of the  
>>> object's name and articleName attribute value that must be unique.  
>>> As long as the combi is unique you can distinguish two HAS and a  
>>> HAS-A instance. Therefore if an object has multiple relationships  
>>> involving child element of the same type a unique articleName  
>>> attribute is mandatory but otherwise articleName attributes were  
>>> optional. In addition articleNames in service inputs or outputs  
>>> were mandatory and quite some time ago articleNames became also  
>>> mandatory for primitives no matter whether there was only one  
>>> relationship involving a certain type of primitive or whether  
>>> there were more.
>>>
>>> So AFAIK the GCP_* objects mentioned below are correctly  
>>> registered according to the current specs, but to keep things  
>>> simple it wouldn't hurt to make articleName attributes always  
>>> mandatory. That would render quite some currently used objects  
>>> invalid though...
>>>
>>> Cheers,
>>>
>>> Pi
>>>
>>> On 25 Mar 2009, at 18:29, Edward Kawas wrote:
>>>
>>>
>>>> Based on what Paul has said, is it true that the datatypes
>>>> (GCP_BiologicalSample, GCP_Germplasm) are then incorrectly  
>>>> registered?
>>>>
>>>> Thanks,
>>>>
>>>> Eddie
>>>>
>>>> -----Original Message-----
>>>> From: moby-dev-bounces at lists.open-bio.org
>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul  
>>>> Gordon
>>>> Sent: March-11-09 10:20 AM
>>>> To: Core developer announcements
>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>
>>>> I can confirm that member articleNames must be unique.  Otherwise  
>>>> there
>>>> would be no way to distinguish two HAS and a HAS-A instance.
>>>>
>>>> Edward Kawas wrote:
>>>>
>>>>> I think that I may have figured it out.
>>>>>
>>>>> Using the datatype SOTest2_validated_cDNA_clone as an example, I  
>>>>> think
>>>>>
>>>> that
>>>>
>>>>> the main problem is that the datatype has 2 has relationships.  
>>>>> It has
>>>>> SOTest2_cDNA and SOTest2_validated. The problem, I think, is  
>>>>> that they
>>>>>
>>>> both
>>>>
>>>>> have the articlename 'has_quality'.
>>>>>
>>>>> I am sure that articlenames in Services have to be unique, but I  
>>>>> can't
>>>>>
>>>> find
>>>>
>>>>> any documentation online saying that articlenames describing  
>>>>> relationships
>>>>> in Datatypes have to be unique as well.
>>>>>
>>>>> So, if articlenames have to be unique, then the registry  
>>>>> inadvertently
>>>>> allowed the registration of datatypes without unique  
>>>>> articlenames for
>>>>> container relationships. Alternatively, if this is allowed, then  
>>>>> a bug was
>>>>> discovered in MoSeS.
>>>>>
>>>>> Anyone have any insight into which one is the correct scenario?
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of  
>>>>> Michael Gerlich
>>>>> Sent: March-11-09 4:14 AM
>>>>> To: Core developer announcements
>>>>> Subject: Re: [MOBY-dev] error installing Biomoby via ant
>>>>>
>>>>> Hi Eddie,
>>>>>
>>>>> I'am using Suns JDK 1.5 Version 16. I also encountered this  
>>>>> behavivour
>>>>> with JDK 6 with compliance level 1.5 (as I had trouble with JDK 6
>>>>> generated services and axis 1.4 and Tomcat5.5).
>>>>>
>>>>> This problem also occurs when I run install from a fresh CVS  
>>>>> checkout
>>>>> (including a fresh Biomoby cache directory). All SOTEST*  
>>>>> datatypes are
>>>>> only registered at Central registry, so they are fetched when  
>>>>> Biomoby
>>>>> fills its cache (retrieving datatypes).
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> What version of JAVA are you using? What registry are you  
>>>>>> generating
>>>>>>
>>>> these
>>>>
>>>>>> datatypes from?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: moby-dev-bounces at lists.open-bio.org
>>>>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of  
>>>>>> Michael Gerlich
>>>>>> Sent: March-10-09 4:28 PM
>>>>>> To: MOBY-dev at lists.open-bio.org
>>>>>> Subject: [MOBY-dev] error installing Biomoby via ant
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I checked out Biomoby from CVS and tried to install it via the
>>>>>>
>>>>>>
>>>>> corresponding
>>>>>
>>>>>
>>>>>> ant tasks, but after fetching all necessary libraries, the  
>>>>>> compilation
>>>>>>
>>>>>>
>>>>> fails
>>>>>
>>>>>
>>>>>> with a lot of error messages regarding datatypes SOTEST*.
>>>>>>
>>>>>> I also encountered this behavior when I tried to run Moses  
>>>>>> Generator for
>>>>>>
>>>>>>
>>>>> one
>>>>>
>>>>>
>>>>>> of my services with an existing Biomoby instance on another  
>>>>>> machine.
>>>>>>
>>>> There
>>>>
>>>>>> the build also fails.
>>>>>> I tested this on 3 different machines, including both Ubuntu  
>>>>>> and XP os.
>>>>>>
>>>>>>
>>>>> The
>>>>>
>>>>>
>>>>>> error log is attached, taken from Dashboad.
>>>>>>
>>>>>> Does anyone encounter similar problems? Should I try cleaning  
>>>>>> Maven
>>>>>> repository, Biomoby cache and/or new Eclipse workspace?
>>>>>>
>>>>>> Thanks in advance and regards,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Excerpt follows (100 error messages like this):
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/datat
>>
>>
>>>>>> ypes/SOTest2_engineered_foreign_gene.java:152: getMoby_Parent()  
>>>>>> in
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_foreign_gene  
>>>>>> cannot
>>>>>>
>>>>>>
>>>>> override
>>>>>
>>>>>
>>>>>> getMoby_Parent() in  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_gene;
>>>>>> attempting to use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign_gene
>>>>>>   [javac] required:
>>>>>>
>>>>>>
>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_region
>>>>>
>>>>>
>>>>>>   [javac]     public SOTest2_foreign_gene getMoby_Parent() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_foreign_transposable_element.java:121:
>>>>>> getMoby_has_quality() in
>>>>>>
>>>>>>
>>>>>>
>> org 
>> .biomoby 
>> .shared.datatypes.SOTest2_engineered_foreign_transposable_element
>>
>>
>>>>>> cannot override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>>>> attempting
>>>>>>
>>>> to
>>>>
>>>>>> use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>>   [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>>   [javac]                              ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_foreign_transposable_element.java:112:
>>>>>>
>>>> getMoby_has_quality()
>>>>
>>>>>> in  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign_transposable_element
>>>>>>
>>>>>>
>>>>> cannot
>>>>>
>>>>>
>>>>>> override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>>>> attempting
>>>>>>
>>>> to
>>>>
>>>>>> use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_foreign[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>>   [javac]     public SOTest2_foreign[] getMoby_has_quality() {
>>>>>>   [javac]                              ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_fusion_gene.java:122:  
>>>>>> getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_fusion_gene  
>>>>>> cannot
>>>>>>
>>>>>>
>>>>> override
>>>>>
>>>>>
>>>>>> getMoby_has_quality() in
>>>>>>
>>>> org.biomoby.shared.datatypes.SOTest2_fusion_gene;
>>>>
>>>>>> attempting to use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_fusion[]
>>>>>>   [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_rescue_region.java:120:  
>>>>>> getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered_rescue_region  
>>>>>> cannot
>>>>>> override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_rescue_region; attempting  
>>>>>> to use
>>>>>> incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_rescue[]
>>>>>>   [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_engineered_transposable_element.java:121:
>>>>>> getMoby_has_quality() in
>>>>>> org 
>>>>>> .biomoby.shared.datatypes.SOTest2_engineered_transposable_element
>>>>>>
>>>>>>
>>>>> cannot
>>>>>
>>>>>
>>>>>> override getMoby_has_quality() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_mobile_genetic_element;  
>>>>>> attempting
>>>>>>
>>>> to
>>>>
>>>>>> use incompatible return type
>>>>>>   [javac] found   :  
>>>>>> org.biomoby.shared.datatypes.SOTest2_engineered[]
>>>>>>   [javac] required: org.biomoby.shared.datatypes.SOTest2_mobile[]
>>>>>>   [javac]     public SOTest2_engineered[] getMoby_has_quality() {
>>>>>>   [javac]                                 ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_five_prime_coding_exon_noncoding_region.java:114:
>>>>>> getMoby_part_of() in
>>>>>>
>>>>>>
>>>>>>
>> org 
>> .biomoby 
>> .shared.datatypes.SOTest2_five_prime_coding_exon_noncoding_region
>>
>>
>>>>>> cannot override getMoby_part_of() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region;  
>>>>>> attempting to use
>>>>>> incompatible return type
>>>>>>   [javac] found   :
>>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>>   [javac] required:  
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>>   [javac]     public SOTest2_five_prime_coding_exon[]  
>>>>>> getMoby_part_of()
>>>>>>
>>>>>>
>>>>> {
>>>>>
>>>>>
>>>>>>   [javac]                                             ^
>>>>>>   [javac]
>>>>>>
>>>>>>
>>>>>>
>> /home/mgerlich/workspace/Biomoby/generated/datatypes/org/biomoby/ 
>> shared/data
>>
>>
>>>>>> types/SOTest2_five_prime_exon_coding_region.java:114:  
>>>>>> getMoby_part_of()
>>>>>>
>>>> in
>>>>
>>>>>> org 
>>>>>> .biomoby.shared.datatypes.SOTest2_five_prime_exon_coding_region  
>>>>>> cannot
>>>>>> override getMoby_part_of() in
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript_region;  
>>>>>> attempting to use
>>>>>> incompatible return type
>>>>>>   [javac] found   :
>>>>>> org.biomoby.shared.datatypes.SOTest2_five_prime_coding_exon[]
>>>>>>   [javac] required:  
>>>>>> org.biomoby.shared.datatypes.SOTest2_transcript[]
>>>>>>   [javac]     public SOTest2_five_prime_coding_exon[]  
>>>>>> getMoby_part_of()
>>>>>>
>>>>>>
>>>>> {
>>>>>
>>>>>
>>>>>>   [javac]
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>> -------------------------------------------------------------
>>> Wageningen University and Research centre (WUR)
>>> Laboratory of Bioinformatics
>>> Transitorium (building 312) room 1034
>>>
>>> Dreijenlaan 3
>>> 6703 HA Wageningen
>>> The Netherlands
>>>
>>> phone:  +31 (0)317-483 060
>>> mobile: +31 (0)6-143 66 783
>>> e-mail: pieter.neerincx at gmail.com
>>> skype:  pieter.online
>>> -------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------





From groscurt at mpiz-koeln.mpg.de  Sat Mar 28 08:58:40 2009
From: groscurt at mpiz-koeln.mpg.de (Andreas Groscurth)
Date: Sat, 28 Mar 2009 09:58:40 +0100
Subject: [MOBY-dev] primitive datatype: Password
In-Reply-To: <49C8A77C.1010104@toulouse.inra.fr>
References: <49C8A77C.1010104@toulouse.inra.fr>
Message-ID: <49CDE6C0.9010501@mpiz-koeln.mpg.de>

Hi...

for the password discussion... there is also an authentication system 
available in moby which can be used to secure your webservices - there 
is no need of sending around your login as any kind of 
datatype/parameter of the service....

please have a look at 
http://www.eu-sol.net/science/bioinformatics/tutorials/secure-biomoby-web-services 
...


AND about the curation / deletion of non-used objects in the 
ontology.... BLOW ME DOWN ;-)

Since when does BioMoby supports this idea... I remember last time this 
discussion was a bit the other way of "Oh no... we cant delete them...."

*g

Cheers
Andreas