The bug has already been reported a year+ ago at https://issues.apache.org/jira/browse/NPANDAY-322 It's resolved with "fixed at 1.2.1", so I added part of my previous e-mail as a comment (I can't re-open the issue in Jira, why?).
Cheers, Stoyan On 11/1/11 10:44 PM, "Stoyan Damov" <[email protected]> wrote: >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. > >
