Thanks for the warm welcome! I'll do my best to help NPanday kill NuGet ;)
I recently spoke to a guy (to remain nameless) at Microsoft (and works with Phil Haack) who said our company is one of the 5 in the world having a .NET & Java division, and that the things I want from NuGet simply don't match the needs of the 80% of NuGet's target group. I simply don't buy that, hence I'm more than happy to contribute to NPanday. He didn't know about Apache Maven and NPanday as well, which as you said is sad. Cheers, Stoyan On 11/2/11 9:45 AM, "Lars Corneliussen" <[email protected]> wrote: >Hi Stoyan, > >welcome to the list! > >We have some "Get Involved" documentation here: >http://incubator.apache.org/npanday/docs/1.4.0-incubating/developers/index >.html > >Preamble: I'm a .NET-guy, as you easily can see on my blog >(http://lcorneliussen.de/blog) > >I agree with you; .NET is way behind Java in terms of build tools. It was >sad for me that the guys at Microsoft that built Nuget (and Guys that >built the preceeding Nu) didn't even know about "Apache Maven" - and >neither about NPanday. The .NET-Community struggles to learn from other >communities. > >I joined the team in October 2010 because I think NPanday is absolutely >the right horse to bet on. But still, there is loads of work to do. > >> 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. > >I guess that about 50% of the Java code is simply dispensable. And the >.NET code is quite badly organized. >I think we rather need concrete improvement suggestions + patches - in >small steps, than a code review :-) > >A year ago I started some work on the VS plugin, refactoring to command >pattern, but I didn't manage to finish it: >https://github.com/lcorneliussen/npanday/commit/5ed038f9bb38a957d40d14bba8 >895ac9337e8aaa > >I also commented on the two issues you mentioned/submitted. >_ >Lars > > >https://github.com/lcorneliussen/npanday/commit/5ed038f9bb38a957d40d14bba8 >895ac9337e8aaa >Am 01.11.2011 um 21:44 schrieb Stoyan Damov: > >> 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(artifac >>t,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. >> >> >
