> I'll do my best to help NPanday kill NuGet ;) I think we could rather use the momentum behind the NuGet Gallery to speed up the adoption of NPanday... Maven encourages lazyness... who will ever download a jar manually? Everything, in every version, is on Maven Central.
But with NPanday you still have to deploy every single .NET-Dependency yourself. If we could leverage Nuget Gallery (groupId 'nuget' :-), or what ever is before the first '.' in the nuget name) that would be a huge benefit: https://issues.apache.org/jira/browse/NPANDAY-372 > 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, Every company with more than 20 developers does Java, .NET and PHP; even Microsoft does Java and PHP. Sad to hear such words from the lonely isle of DevDiv. > 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. Me neither; and again welcome! The road to become a committer isn't hard either - after a few good patches, that drive the project in the correct direction, we'll set up you up for a vote :-) _ Lars Am 02.11.2011 um 09:42 schrieb Stoyan Damov: > 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. >>> >>> >> > >
