UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

Hello,
like I said already, I am browsing through the API and adding JavaDoc to 
  some classes. Right now I have a problem concerning the UpdaterConfig. 
This class is called all over the API and should provide basic 
configuration for the application. But right now, I am pretty unsure, 
how this configuration is provided to the calling classes.
Also please note, that there seems to be an endless loop in the method 
listArtifacts(...) in the class AbstractHierarchicalRepositories. Or is 
there any need for this?

R,

Markus

Re: UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

No Problem. It made me nervous as well. We checked in pretty much the 
same time :-)
Anyway, I looked through the code I changed, and it does not look like 
there are any functional changes.

Markus

Adam R. B. Jack wrote:
> 
> 
> 
>>You are right, you touched the DownloaderTool. But I believe that I did
>>not checkin any version of DownloaderTool, where functional changes are
>>done. Take a look at the class. It should work.
>>But ...
> 
> 
> This (from one of your  SVN commit message) is what made me nervous:
> 
> --------------------------------------------------------
> Modified:
> 
> incubator/depot/trunk/update/src/java/org/apache/depot/update/tool/Downloade
> rTool.java
> 
> incubator/depot/trunk/update/src/java/org/apache/depot/update/tool/Tool.java
> Log:
> Added UpdaterConfig once again
> 
> 
> --------------------------------------------------------
> 
> regards
> 
> Adam
> 
> 

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> You are right, you touched the DownloaderTool. But I believe that I did
> not checkin any version of DownloaderTool, where functional changes are
> done. Take a look at the class. It should work.
> But ...

This (from one of your  SVN commit message) is what made me nervous:

--------------------------------------------------------
Modified:

incubator/depot/trunk/update/src/java/org/apache/depot/update/tool/Downloade
rTool.java

incubator/depot/trunk/update/src/java/org/apache/depot/update/tool/Tool.java
Log:
Added UpdaterConfig once again


--------------------------------------------------------

regards

Adam

Re: UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

You are right, you touched the DownloaderTool. But I believe that I did 
not checkin any version of DownloaderTool, where functional changes are 
done. Take a look at the class. It should work.
But ...

Markus

Adam R. B. Jack wrote:
> Markus wrote:
> 
> 
>>from what I have seen basically nothing. You did some stuff in other
>>classes.
> 
> 
> How strange, I swear I touched overlapping classes (such as DownloadTool).
> Oh well, maybe I'm just nuts. Also, I swear things (some) were working, I
> did update, they stopped. Oh well, no biggee -- I'll dig back in and try to
> figure things out. Sorry for the noise.
> 
> regards
> 
> Adam
> 
> 

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

Markus wrote:

> from what I have seen basically nothing. You did some stuff in other
> classes.

How strange, I swear I touched overlapping classes (such as DownloadTool).
Oh well, maybe I'm just nuts. Also, I swear things (some) were working, I
did update, they stopped. Oh well, no biggee -- I'll dig back in and try to
figure things out. Sorry for the noise.

regards

Adam

Re: UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

Hello,
from what I have seen basically nothing. You did some stuff in other 
classes.

Markus



Adam R. B. Jack wrote:
>>>Basically what I did, is, that I totally recovered/resurrected the
> 
> version
> 
>>>before the deletion of UpdaterConfig.
>>
>>Huh? Oh no! I did a tonne of work yesterday. How much of that is gone?
>>
>>
>>>I
>>>recovered these files, and hope that I did not undo any changes you did
>>
>>:-)
>>
>>I think you did. Did you recover a whole version, or recover files from a
>>version? Can we restore my work (even if it means loosing the
>>UpdaterConfig.configure calls) and then simply restoring UpdaterConfig
>>(which is what I thought you first did). Basically I can wire it back in,
> 
> if
> 
>>the file (hopefully the latest) is there. But, I can't stand the thought
> 
> of
> 
>>loosing all the debugging/fixing work I put in yesterday, I can't easily
>>remember what it all was.
> 
> 
> Please let me know if you can work on this today (or ever) and if not I'll
> either figure out how to do it myself, or plan my day to work on something
> different.
> 
> regards
> 
> Adam
> 
> 

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> > Basically what I did, is, that I totally recovered/resurrected the
version
> > before the deletion of UpdaterConfig.
>
> Huh? Oh no! I did a tonne of work yesterday. How much of that is gone?
>
> > I
> > recovered these files, and hope that I did not undo any changes you did
> :-)
>
> I think you did. Did you recover a whole version, or recover files from a
> version? Can we restore my work (even if it means loosing the
> UpdaterConfig.configure calls) and then simply restoring UpdaterConfig
> (which is what I thought you first did). Basically I can wire it back in,
if
> the file (hopefully the latest) is there. But, I can't stand the thought
of
> loosing all the debugging/fixing work I put in yesterday, I can't easily
> remember what it all was.

Please let me know if you can work on this today (or ever) and if not I'll
either figure out how to do it myself, or plan my day to work on something
different.

regards

Adam

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> Once again.
> I think I was a little hasty to check this stuff in, without checking once
> again, if this stuff is used anyhow. Right now, I still have an open issue
> with the artifacttest class, I hope I can resolve tonight.

Let us know what it is, maybe we can help.

> Basically what I did, is, that I totally recovered/resurrected the version
> before the deletion of UpdaterConfig.

Huh? Oh no! I did a tonne of work yesterday. How much of that is gone?

> This is pretty easy, since you can do
> a "svn log --verbose" and get all the changes for a given directory. If
you
> need to know more, I strongly recommed
> http://svnbook.red-bean.com/svnbook/ch04s04.html#svn-ch-4-sect-4.3. I am
> also just using plain commandline, and only sometimes the eclipse version.

I will thanks.

> I
> recovered these files, and hope that I did not undo any changes you did
:-)

I think you did. Did you recover a whole version, or recover files from a
version? Can we restore my work (even if it means loosing the
UpdaterConfig.configure calls) and then simply restoring UpdaterConfig
(which is what I thought you first did). Basically I can wire it back in, if
the file (hopefully the latest) is there. But, I can't stand the thought of
loosing all the debugging/fixing work I put in yesterday, I can't easily
remember what it all was.

I put a lot of effort into Depot yesterday, and I was hoping to build upon
it today. Is there any way we can unwind this tangle w/o getting deeper into
trouble?

Do we need to get a plan straight before we touch SVN any more, before we
mis-communicate and cause more grief?

regards

Adam

Re: UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

Once again. 
I think I was a little hasty to check this stuff in, without checking once
again, if this stuff is used anyhow. Right now, I still have an open issue
with the artifacttest class, I hope I can resolve tonight.
Basically what I did, is, that I totally recovered/resurrected the version
before the deletion of UpdaterConfig. This is pretty easy, since you can do
a "svn log --verbose" and get all the changes for a given directory. If you
need to know more, I strongly recommed
http://svnbook.red-bean.com/svnbook/ch04s04.html#svn-ch-4-sect-4.3. I am
also just using plain commandline, and only sometimes the eclipse version. I
recovered these files, and hope that I did not undo any changes you did :-)

R,

Markus
> 
> > Sorry, a little to hasty. rebuild the stuff. right now i still have the
> > artifacttest where some work has to be done.
> 
> Not sure I follow these sentences.
> 
> > to recover (resurrect) a deleted file, you have to find out the old
> > revision number and copy it (svn copy) to the working copy. then just
> > add it once again. pretty straight forward, i think :-)
> 
> I think I follow, although I don't know how to query history.
> BTW: I gve up on Subclipse yet again, can't whittle well with it...
> 
> Q: Did you merge w/ any changes I've jsut made, or does SVN allow you to
> copy over w/o a merge?
> 
> > sorry once again.
> 
> Nope, don't be. If our unit tests were all working before you did that,
> maybe
> 
> regards
> 
> Adam
> 

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> Sorry, a little to hasty. rebuild the stuff. right now i still have the
> artifacttest where some work has to be done.

Not sure I follow these sentences.

> to recover (resurrect) a deleted file, you have to find out the old
> revision number and copy it (svn copy) to the working copy. then just
> add it once again. pretty straight forward, i think :-)

I think I follow, although I don't know how to query history.
BTW: I gve up on Subclipse yet again, can't whittle well with it...

Q: Did you merge w/ any changes I've jsut made, or does SVN allow you to
copy over w/o a merge?

> sorry once again.

Nope, don't be. If our unit tests were all working before you did that,
maybe

regards

Adam

Re: UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

Sorry, a little to hasty. rebuild the stuff. right now i still have the 
artifacttest where some work has to be done.

to recover (resurrect) a deleted file, you have to find out the old 
revision number and copy it (svn copy) to the working copy. then just 
add it once again. pretty straight forward, i think :-)

sorry once again.

Markus

Adam R. B. Jack wrote:
>>>That said, I suspect this is used more than we realize. We'll see.
> 
> 
> FWIIW: UpdaterConfig would read the local depot-update.xml resource (from
> JAR or otherwise) and would configure a bunch of named repositories, and
> such. This is kinda like the types in ant, but it allows us to ship (or
> locally configure) a default set of things.
> 
> Right now we have code that tries to get named entities from the
> ReferenceManager.
> 
> I am +1 to get rid of stuff in the way, or not being used, but not stuff
> that is used.
> 
> regards,
> 
> Adam
> 
> 

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> > That said, I suspect this is used more than we realize. We'll see.

FWIIW: UpdaterConfig would read the local depot-update.xml resource (from
JAR or otherwise) and would configure a bunch of named repositories, and
such. This is kinda like the types in ant, but it allows us to ship (or
locally configure) a default set of things.

Right now we have code that tries to get named entities from the
ReferenceManager.

I am +1 to get rid of stuff in the way, or not being used, but not stuff
that is used.

regards,

Adam

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> > +1 for removal of everything unused and not needed right now. after we
> > have cleared the API we could add this once again. there is still svn
> > which takes care about backups :-)
>
> Yup, we have enough to do to get all we want in context w/o extras, I
agree.
> +1.
>
> That said, I suspect this is used more than we realize. We'll see.

Sorry, I worded this poorly. I meant, I agree we ought trim but I don't
think we can trim this, it is used. Running the unit tests (and them not
working) tells me we can't.

1) Who did this?
2) Did they run unit tests before and/or afterwards?
3) Anybody know how to recover stuff from SVN? Daft as it sounds, I don't
know how to (I don't know if a concept of ATTIC exists.)

regards,

Adam

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> +1 for removal of everything unused and not needed right now. after we
> have cleared the API we could add this once again. there is still svn
> which takes care about backups :-)

Yup, we have enough to do to get all we want in context w/o extras, I agree.
+1.

That said, I suspect this is used more than we realize. We'll see.

regards,

Adam

Re: UpdaterConfig

["Markus M. May" <mm...@gmx.net>]

+1 for removal of everything unused and not needed right now. after we 
have cleared the API we could add this once again. there is still svn 
which takes care about backups :-)
Nick Chalko wrote:
> Adam R. B. Jack wrote:
> 
>>> like I said already, I am browsing through the API and adding JavaDoc to
>>>  some classes. Right now I have a problem concerning the UpdaterConfig.
>>> This class is called all over the API and should provide basic
>>> configuration for the application. But right now, I am pretty unsure,
>>> how this configuration is provided to the calling classes.
>>>   
>>
>>
>> That was (is?) a nice experiment by Anou. Basically we wanted some 
>> form of
>> 'ant types' (configuration in XML) but outside of Ant. The configuration
>> file is read, and named configured objects are stored in a registry (by
>> namespaced name).
>>
>> I think it works, but has some usage issues, so right now I'm kinda 
>> hoping
>> to leave it on the side, until we find time to work on it. I do like the
>> idea.
>>  
>>
> My preference is to CUT what is not being used. If there is not a test 
> case that exercise this,  ask about it on the list and then we can kill it.
> 
> R,
> Nick
> 
> 

Re: UpdaterConfig

[Nick Chalko <ni...@chalko.com>]

Adam R. B. Jack wrote:

>>like I said already, I am browsing through the API and adding JavaDoc to
>>  some classes. Right now I have a problem concerning the UpdaterConfig.
>>This class is called all over the API and should provide basic
>>configuration for the application. But right now, I am pretty unsure,
>>how this configuration is provided to the calling classes.
>>    
>>
>
>That was (is?) a nice experiment by Anou. Basically we wanted some form of
>'ant types' (configuration in XML) but outside of Ant. The configuration
>file is read, and named configured objects are stored in a registry (by
>namespaced name).
>
>I think it works, but has some usage issues, so right now I'm kinda hoping
>to leave it on the side, until we find time to work on it. I do like the
>idea.
>  
>
My preference is to CUT what is not being used. 
If there is not a test case that exercise this,  ask about it on the 
list and then we can kill it.

R,
Nick

Re: UpdaterConfig

["Adam R. B. Jack" <aj...@trysybase.com>]

> like I said already, I am browsing through the API and adding JavaDoc to
>   some classes. Right now I have a problem concerning the UpdaterConfig.
> This class is called all over the API and should provide basic
> configuration for the application. But right now, I am pretty unsure,
> how this configuration is provided to the calling classes.

That was (is?) a nice experiment by Anou. Basically we wanted some form of
'ant types' (configuration in XML) but outside of Ant. The configuration
file is read, and named configured objects are stored in a registry (by
namespaced name).

I think it works, but has some usage issues, so right now I'm kinda hoping
to leave it on the side, until we find time to work on it. I do like the
idea.

> Also please note, that there seems to be an endless loop in the method
> listArtifacts(...) in the class AbstractHierarchicalRepositories. Or is
> there any need for this?

I suspect it was another bug introduced in the global renaming, when
Artifact(Resource)Specifer -> Artifact, and Artifact(Resource) ->
ArtifactInstance. There are a few cases where a cal lto something w/ type
ArtifactSpecifer lost the Specifer, and hence changing the intended called
method. I'll look into it, thanks.

regards

Adam