Correct list; no rules violated! :) Regarding the state of the .NET-Code: I could't agree more. And it is not much better on the Java side; but still the right horse to bet on!!
I'll answer more in detail tomorrow! cheers, Lars _ Mobil versendet. Am 01.11.2011 um 21:44 schrieb Stoyan Damov <[email protected]>: > Hi guys, > > First, sorry if the I'm not following the "protocol" for sending a single > thing in one e-mail (e.g. this is a question, a bug report, and a feature > request) but I couldn't find a "How to send e-mails to this list" link. > > Our company is evaluating NPanDay for use by our the .NET team (the Java > team is already using maven), mainly to get rid of NuGet as a "dependency > management" system with which we're not at all happy, but also to have a > common toolset (.NET tools are years behind the ones for Java). > From my little experience with NPanDay I believe it's the cure we were > looking for (we were interested in NPanDay for quite some time but because > we're using .NET framework 4 & VS 2010 previous versions were not worth > evaluating). > > I found some problems (described below) in NPanDay.VisualStudio.Plugin > (mainly in ReferenceManager) which I Q&D fixed. However, I'd like to > actually do a more thorough code review & make the best possible fix, and > then propose it. > I couldn't find what's the "ceremony" of submitting a patch, hence I'm > asking on this list. Sorry if that's not the right place for that. > > The first bug is in "Resync references" which calls > ReferenceManager.CopyArtifact: > > if (!artifact.FileInfo.Exists || artifact.Version.EndsWith("SNAPSHOT")) > { > if > (!NPanday.ProjectImporter.Digest.Model.Reference.DownloadArtifact(artifact,l > ogger)) > { > ReferenceErrorEventArgs e = new ReferenceErrorEventArgs(); > e.Message = string.Format("Unable to get the artifact {0} from any > of your repositories.", artifact.ArtifactId); > onError(e); > return; > } > } > > The check for SNAPSHOT above forces "Resync references" to try and download > the artifact off the remote repository. > If the artifact is not yet installed (which is common if I'm developing a > new module but don't want to commit/push it yet), what happens is that: > 1. The resync fails (which is bad) and > 2. If the artifact is installed in the local repo, it gets deleted (which is > worse) > > What should happen (for SNAPSHOTs) instead is this: > > 1. Try to get timestamp of artifact in remote repo. If that fails, it > shouldn't be a problem, the artifact might not be deployed (yet). > 2. Try to get timestamp of artifact in local repo. If that fails, then this > is an error and should be reported. > 3. Get the timestamp of the local file (in .references/...) > 4. If there's a remote timestamp and it's greater than the local one, update > the local repo's artifact. > 5. If the local repo's timestamp (possibly updated at point 4) is greater > than the timestamp of the local file, update the file in .references/... > > For steps 1 and 2 use the timestamp in maven-metadata.xml (in > ReferenceManager.copyToReferenceFolder there's already a TODO which suggests > to use "<metadata>/<versioning>/<lastUpdated>" for the timestamp). > Currently, the local repo's timestamp is considered to be the file's last > write time (not even .LastWriteTimeUtc, which is another bug). > > To make it clear, since we're all developers, here's the algo in pseudo code > (this might not compile, I'm writing it in Outlook): > > DateTime remoteRepoTimestamp, localRepoTimestamp, localFileTimestamp; > bool hasRemoteTimestamp =TryGetArtifactRemoteRepositoryTimestamp(artifact, > logger, out remoteRepoTimestamp); > bool hasLocalRepoTimestamp = > TryGetArtifactLocalRepositoryTimestamp(artifact, logger, out > localRepoTimestamp); > localFileTimestamp = GetLocalFileTimestamp(artifact.FileInfo, logger); > if (hasRemoteTimestamp && hasLocalRepoTimestamp && remoteRepoTimestamp > > localRepoTimestamp) > { > UpdateLocalRepoArtifact(); // == > NPanday.ProjectImporter.Digest.Model.Reference.DownloadArtifact(artifact, > logger) > // ^^ error handling above omitted for brevity > localRepoTimestamp = remoteRepoTimestamp; > } > if (hasLocalRepoTimestamp && localRepoTimestamp > localFileTimestamp) > { > copyToReferenceFolder(artifact, referenceFolder); > } > > Something like this. > > > The 2nd thing is that there's a pretty good case to have "Resync references > from *local* repo" and "Resync references" (from remote, which is described > in the bug above). > "Resync references from local repo" should skip the remote repo. Here's the > valid case: > > I'm working on X and Y. I make a change in X and "maven install" it (in the > local repo). I don't push the changes to the SCM. > Y has a dependency on X and I want to resync the references so that I get > the updated X dependency. Currently I can't do that. > > I can't (don't want to) push X's changes and wait on the build server to > deploy the new snapshot because I don't want to "hurt" the rest of the > developers with something which might still have bugs in it. > > Hope both the 1st bug & the feature request (it's more a feature request) > are clear. Let me know if I should elaborate. > > One more thing. No offense but the current code base (I have only looked at > the .NET code so far) needs some cleaning up (TODOs, XML "parsing", etc.). > Let me know if you're interested in a code review and to who I should e-mail > it, also I'll be more than glad to do most of the clean up myself if I'd be > allowed to push/propose changes. > > Cheers, > > > Stoyan Damov > > Head of Development > Pirinsoft Bulgaria Ltd. > > 40 Atanas Moskov str., fl.2 > Business Center Vitosha > 1715 Sofia, Bulgaria > > Tel: +359 2 421 85 10 > Fax: +359 2 421 85 15 > Mobile: +359 892 493 336 > E-mail: [email protected] > > This communication (including any attachments) contains proprietary > information some or all of which may be legally privileged. Unless you are > the intended recipient (or authorized to receive for the intended > recipient), you must not print, retain, use, copy, distribute or disclose to > anyone this message or any information contained in it. If you receive this > e-mail in error, please notify the author immediately by replying to this > e-mail and then delete it from your system. E-mail transmission cannot be > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message, which arise as a result of e-mail > transmission. > >
