[MOBY-dev] error installing Biomoby via ant

markw at illuminae.com markw at illuminae.com
Thu Mar 26 15:25:33 UTC 2009 

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

More information about the MOBY-dev mailing list