Thread: [Treebase-devel] Deletion of cipres framework

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I checked into TreeBase code and found 7 java classes still need cipres
framework 1.1 to compile. I suggest we keep it for now.

Youjun

I agree: more investigation looks like too much trouble now, so I  
filed a bug note for the future.
--VG

On Jan 14, 2010, at 3:46 PM, youjun guo wrote:

> I checked into TreeBase code and found 7 java classes still need  
> cipres framework 1.1 to compile. I suggest we keep it for now.
>
> Youjun
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

Can we give those 7 java classes some more attention as to why they  
are needing the CIPRES framework to compile? Let's remember, we know  
for a fact that code that relies on that framework is guaranteed not  
to function.

We should at least know what it is in those 7 classes that we know  
can't be functional because it needs the CIPRES framework. Leaving  
that code in there because we need it is the same as saying, there is  
code in there that we need but that we know doesn't work. I'm not  
comfortable with this.

	-hilmar

On Jan 14, 2010, at 3:46 PM, youjun guo wrote:

> I checked into TreeBase code and found 7 java classes still need  
> cipres framework 1.1 to compile. I suggest we keep it for now.
>
> Youjun
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================

Hilmar,

This code refactoring may take a week or a bit longer, should I proceed?

Youjun

On Thu, Jan 14, 2010 at 4:43 PM, Hilmar Lapp <hl...@ne...> wrote:

> Can we give those 7 java classes some more attention as to why they are
> needing the CIPRES framework to compile? Let's remember, we know for a fact
> that code that relies on that framework is guaranteed not to function.
>
> We should at least know what it is in those 7 classes that we know can't be
> functional because it needs the CIPRES framework. Leaving that code in there
> because we need it is the same as saying, there is code in there that we
> need but that we know doesn't work. I'm not comfortable with this.
>
> -hilmar
>
>
> On Jan 14, 2010, at 3:46 PM, youjun guo wrote:
>
> I checked into TreeBase code and found 7 java classes still need cipres
> framework 1.1 to compile. I suggest we keep it for now.
>
> Youjun
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
>
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel
>
>
> --
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
>

I'm against doing that now, given the time constraints we're under.

On Friday, January 15, 2010, youjun guo <you...@ya...> wrote:
> Hilmar,
>
> This code refactoring may take a week or a bit longer, should I proceed?
>
>
>
> Youjun
>
>
>
> On Thu, Jan 14, 2010 at 4:43 PM, Hilmar Lapp <hl...@ne...> wrote:
> Can we give those 7 java classes some more attention as to why they are needing the CIPRES framework to compile? Let's remember, we know for a fact that code that relies on that framework is guaranteed not to function.
>
> We should at least know what it is in those 7 classes that we know can't be functional because it needs the CIPRES framework. Leaving that code in there because we need it is the same as saying, there is code in there that we need but that we know doesn't work. I'm not comfortable with this.
>
> 	-hilmar
>
> On Jan 14, 2010, at 3:46 PM, youjun guo wrote:
>
> I checked into TreeBase code and found 7 java classes still need cipres framework 1.1 to compile. I suggest we keep it for now.
>
> Youjun
>  ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel
>
>
> -- ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :===========================================================
>
>
>
>
>

-- 
Dr. Rutger A. Vos
School of Biological Sciences
Philip Lyle Building, Level 4
University of Reading
Reading
RG6 6BX
United Kingdom
Tel: +44 (0) 118 378 7535
http://www.nexml.org
http://rutgervos.blogspot.com

Maybe I haven't made myself clear. Code that uses those classes *will  
not work*. We know that. It may compile, but it *will not work*.

So I don't understand what the difference can be for the running  
application if we delete all code segments that we know *will not  
work*. How can it be better to leave that in?

I'm willing to be educated here, but what I'm hearing is that there is  
a potentially large part of the TB2 web-application that we know does  
not work. Or is it a small part only? It seems to me that we don't  
know. I don't understand what is the benefit of going live with this.  
This is a show-stopper in my eyes.

Either the code that doesn't work isn't needed to begin with, and then  
we might as well delete it, or it is needed. If it is needed, nobody  
has been able so far to state which functions are affected so we can't  
make a criticality assessment.

So my rather strong vote is to investigate this to the point that we  
at least understand what is affected. If the problem is primarily that  
removing that guaranteed to be dysfunctional code simply takes up time  
to make everything compile again but none of it is exposed through the  
UI, then I can totally live with that for the release. But based on  
what I'm hearing we're not even close to understanding that this is  
the situation we are having.

	-hilmar

On Jan 15, 2010, at 8:17 AM, Rutger Vos wrote:

> I'm against doing that now, given the time constraints we're under.
>
> On Friday, January 15, 2010, youjun guo <you...@ya...> wrote:
>> Hilmar,
>>
>> This code refactoring may take a week or a bit longer, should I  
>> proceed?
>>
>>
>>
>> Youjun
>>
>>
>>
>> On Thu, Jan 14, 2010 at 4:43 PM, Hilmar Lapp <hl...@ne...>  
>> wrote:
>> Can we give those 7 java classes some more attention as to why they  
>> are needing the CIPRES framework to compile? Let's remember, we  
>> know for a fact that code that relies on that framework is  
>> guaranteed not to function.
>>
>> We should at least know what it is in those 7 classes that we know  
>> can't be functional because it needs the CIPRES framework. Leaving  
>> that code in there because we need it is the same as saying, there  
>> is code in there that we need but that we know doesn't work. I'm  
>> not comfortable with this.
>>
>> 	-hilmar
>>
>> On Jan 14, 2010, at 3:46 PM, youjun guo wrote:
>>
>> I checked into TreeBase code and found 7 java classes still need  
>> cipres framework 1.1 to compile. I suggest we keep it for now.
>>
>> Youjun
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently  
>> attracts the
>> world's best and brightest in the field, creating opportunities for  
>> Conference
>> attendees to learn about information security's most important  
>> issues through
>> interactions with peers, luminaries and emerging and established  
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
>> Treebase-devel mailing list
>> Tre...@li...
>> https://lists.sourceforge.net/lists/listinfo/treebase-devel
>>
>>
>> -- ===========================================================
>> : Hilmar Lapp  -:- Durham, NC -:-  
>> informatics 
>> .nescent 
>> .org :===========================================================
>>
>>
>>
>>
>>
>
> -- 
> Dr. Rutger A. Vos
> School of Biological Sciences
> Philip Lyle Building, Level 4
> University of Reading
> Reading
> RG6 6BX
> United Kingdom
> Tel: +44 (0) 118 378 7535
> http://www.nexml.org
> http://rutgervos.blogspot.com

-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================

Hilmar,

The difficult part is identify the "dead code" and the "living code". In
most of the case "dead code" and "living code" are mixed in same java file.
Every deletion can break some other java file which refer to the deleted
code.

The "Investigation" is actually almost the same efforts as delete and fix. I
will  prefer deletion over investigation. I will try to delete a  nclXXX
class which Bill Identify as definitely a dead class and see how it is going

Youjun

OK, let's hear first of all which classes are affected. I've never
seen them in action so I doubt they're exposed through the UI - in
which case spending a week on it isn't time we should be spending
*right now*.

I understand what you're saying, but my gut feeling is simply that
they don't affect the web app or we would have seen bugs that involve
these classes earlier.

On Fri, Jan 15, 2010 at 2:46 PM, Hilmar Lapp <hl...@ne...> wrote:
> Maybe I haven't made myself clear. Code that uses those classes *will not
> work*. We know that. It may compile, but it *will not work*.
>
> So I don't understand what the difference can be for the running application
> if we delete all code segments that we know *will not work*. How can it be
> better to leave that in?
>
> I'm willing to be educated here, but what I'm hearing is that there is a
> potentially large part of the TB2 web-application that we know does not
> work. Or is it a small part only? It seems to me that we don't know. I don't
> understand what is the benefit of going live with this. This is a
> show-stopper in my eyes.
>
> Either the code that doesn't work isn't needed to begin with, and then we
> might as well delete it, or it is needed. If it is needed, nobody has been
> able so far to state which functions are affected so we can't make a
> criticality assessment.
>
> So my rather strong vote is to investigate this to the point that we at
> least understand what is affected. If the problem is primarily that removing
> that guaranteed to be dysfunctional code simply takes up time to make
> everything compile again but none of it is exposed through the UI, then I
> can totally live with that for the release. But based on what I'm hearing
> we're not even close to understanding that this is the situation we are
> having.
>
>        -hilmar
>
> On Jan 15, 2010, at 8:17 AM, Rutger Vos wrote:
>
>> I'm against doing that now, given the time constraints we're under.
>>
>> On Friday, January 15, 2010, youjun guo <you...@ya...> wrote:
>>>
>>> Hilmar,
>>>
>>> This code refactoring may take a week or a bit longer, should I proceed?
>>>
>>>
>>>
>>> Youjun
>>>
>>>
>>>
>>> On Thu, Jan 14, 2010 at 4:43 PM, Hilmar Lapp <hl...@ne...> wrote:
>>> Can we give those 7 java classes some more attention as to why they are
>>> needing the CIPRES framework to compile? Let's remember, we know for a fact
>>> that code that relies on that framework is guaranteed not to function.
>>>
>>> We should at least know what it is in those 7 classes that we know can't
>>> be functional because it needs the CIPRES framework. Leaving that code in
>>> there because we need it is the same as saying, there is code in there that
>>> we need but that we know doesn't work. I'm not comfortable with this.
>>>
>>>        -hilmar
>>>
>>> On Jan 14, 2010, at 3:46 PM, youjun guo wrote:
>>>
>>> I checked into TreeBase code and found 7 java classes still need cipres
>>> framework 1.1 to compile. I suggest we keep it for now.
>>>
>>> Youjun
>>>
>>> ------------------------------------------------------------------------------
>>> Throughout its 18-year history, RSA Conference consistently attracts the
>>> world's best and brightest in the field, creating opportunities for
>>> Conference
>>> attendees to learn about information security's most important issues
>>> through
>>> interactions with peers, luminaries and emerging and established
>>> companies.
>>>
>>> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
>>> Treebase-devel mailing list
>>> Tre...@li...
>>> https://lists.sourceforge.net/lists/listinfo/treebase-devel
>>>
>>>
>>> -- ===========================================================
>>> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org
>>> :===========================================================
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Dr. Rutger A. Vos
>> School of Biological Sciences
>> Philip Lyle Building, Level 4
>> University of Reading
>> Reading
>> RG6 6BX
>> United Kingdom
>> Tel: +44 (0) 118 378 7535
>> http://www.nexml.org
>> http://rutgervos.blogspot.com
>
> --
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
>

-- 
Dr. Rutger A. Vos
School of Biological Sciences
Philip Lyle Building, Level 4
University of Reading
Reading
RG6 6BX
United Kingdom
Tel: +44 (0) 118 378 7535
http://www.nexml.org
http://rutgervos.blogspot.com

Ok, here is my test report:

A group of TreeBase classes use cipres framework to establish the gateway to
access NCL facility. Those classes need to delete if we delete the
framework.

NCL is a nexus file parsing tool similar to the Mesquite. According to Bill
NCL is not used by TreeBase anymore(It's hard to tell from the code), since
we had Mesquite.

There are 7 NCL related classes in main code need be deleted. In order  to
get the test result I already deleted them from my eclipse

But there are code take both NCL and Mesquite as nexus parser choices. Those
code need to be fix if we take NCL option off.

Besides, deleting cipres framework and NCL stuff cause 100 complains across
about 20 test classes .

Youjun

Dear All,

I am working on the deletion of cipres framework, please be noted that after
this deletion all the TB code which refer to  the type PhyloDataset
(org.cipres.datatypes) will not work and have to be deleted also.

I do find some classes refer to this type.  The classes are located in
"test" directory, but do not look like test classes. The package name is
org.cipres.treebase.migtation.

Also a AbstractPhyloDataSet and all classes extends this class will not work
anymore.

Youjun.

OK, I notice right now some test classes fail to compile in eclipse. I
assume you're not done with your commits yet.

On Tue, Jan 19, 2010 at 3:06 PM, youjun guo <you...@ya...> wrote:
> Dear All,
>
> I am working on the deletion of cipres framework, please be noted that after
> this deletion all the TB code which refer to  the type PhyloDataset
> (org.cipres.datatypes) will not work and have to be deleted also.
>
> I do find some classes refer to this type.  The classes are located in
> "test" directory, but do not look like test classes. The package name is
> org.cipres.treebase.migtation.
>
> Also a AbstractPhyloDataSet and all classes extends this class will not work
> anymore.
>
> Youjun.

-- 
Dr. Rutger A. Vos
School of Biological Sciences
Philip Lyle Building, Level 4
University of Reading
Reading
RG6 6BX
United Kingdom
Tel: +44 (0) 118 378 7535
http://www.nexml.org
http://rutgervos.blogspot.com

Hi Youjun,

thanks for this investigation - this makes things a lot clearer. With  
this understanding below, I would have actually been OK with  
postponing fixing it to after the release, but I see you've forged  
ahead already, which is great too.

	-hilmar

On Jan 15, 2010, at 2:51 PM, youjun guo wrote:

> Ok, here is my test report:
>
> A group of TreeBase classes use cipres framework to establish the  
> gateway to access NCL facility. Those classes need to delete if we  
> delete the framework.
>
> NCL is a nexus file parsing tool similar to the Mesquite. According  
> to Bill NCL is not used by TreeBase anymore(It's hard to tell from  
> the code), since we had Mesquite.
>
> There are 7 NCL related classes in main code need be deleted. In  
> order  to get the test result I already deleted them from my eclipse
>
> But there are code take both NCL and Mesquite as nexus parser  
> choices. Those code need to be fix if we take NCL option off.
>
> Besides, deleting cipres framework and NCL stuff cause 100 complains  
> across about 20 test classes .
>
> Youjun

-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================

>
> do find some classes refer to this type.  The classes are located in "test"
> directory, but do not look like test classes. The package name is
> org.cipres.treebase.migtation.
>
> Also a AbstractPhyloDataSet and all classes extends this class will not
> work anymore
>

Since the efforts we already paid,  If no one complain with the two above
issues, I will keep working and expect to finish this week.

YOujun