Re: UpdaterConfig

[Markus M. May]

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]

  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

[Markus M. May]

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]

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]

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]

 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]

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]

  +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

[Markus M. May]

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]

 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]

 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

Re: UpdaterConfig

[Nick Chalko]

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

[Markus M. May]

+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