Anybody have problems with requiring versions in the filename/assemblyname?
On 10/15/07, Shane Isbell <[EMAIL PROTECTED]> wrote: > > Hi Evan, > > You can use versions in the file name, it's just that it changes the way > the assembly is loaded. See > > > http://www.jroller.com/random7/entry/apache_nmaven_repository_structure_and > > http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documents > > > for some explanation. If you recall, we went down the path of versioning > in the remote repos and not versioning in the local repo (look at the blog > entry above for a more detailed explanation). It was all of these problems > which led me to rewrite the resolver and split the repository. From my > perspective, I'm not too keen on the "copy the assembly approach", not > because I don't think we can't make it work, but because I think that it > gets way too complicated. Remember, we also need to support at least a > single classifier, attached artifacts and snapshots, so it promises to get > more complicated with all the renaming and overlapping repos. > > Regards, > Shane > > On 10/15/07, Evan Worley <[EMAIL PROTECTED]> wrote: > > > > Hi Shane, > > > > Isn't one of the underlying problems that the .net framework does not > > allow > > for versions in the file name? This is why we have utilized the > > AssemblyInfo in the past. Would the strategy still be to have versioned > > files in remote repos, but rename the latest version to be version-less > > in > > the local repository? > > > > Thanks, > > Evan > > > > On 10/15/07, Shane Isbell < [EMAIL PROTECTED]> wrote: > > > > > > Hi Jason, > > > > > > We can isolate the two main issues as 1) RDF: this is there to provide > > > tool-chain/classifier/capabilities support; 2) resolving has problems > > > largely deriving from removing of versions from the file name. > > > > > > If everyone is okay pushing off the tool chain and/or capabilities > > > support, > > > then we can dump it. Admittedly, this is a huge part of NMaven but it > > does > > > make it tougher to jump into the code and if no one needs this right > > now, > > > then it's more of hindrance than anything. > > > > > > In regards to (2), including a version in the file name enforces a > > type of > > > strong name loading. You won't be able to just swap out different > > versions > > > of assemblies during runtime, but rather you'll need to recompile the > > > whole > > > chain of assemblies. Personally, I think we're going to need signed > > > assemblies in the public open-source repositories, so including > > versions > > > in > > > the filename won't be a big deal. The problem with including versions > > in > > > the > > > file name would occur for things like web apps (or executables) that > > have > > > private application spaces, where someone wants to just plop in a new > > > version of their assembly and restart the application. In this case, > > they > > > may need to recompile a number of assemblies (even transitive > > relations) > > > that depend on that assembly. I'm also okay with including versions in > > the > > > file name, as long as everyone accepts and can deal with the > > limitations. > > > This would very quickly bring NMaven back in line with Maven. > > > > > > If we can get a discussion going and then a vote, we can move quickly > > to > > > start making any changes. > > > > > > Regards, > > > Shane > > > > > > > > > On 10/14/07, Jason van Zyl < [EMAIL PROTECTED]> wrote: > > > > > > > > Hi Shane, > > > > > > > > Do you have any plans for switching the local repository mechanism > > > > back to using POMs? > > > > > > > > I would at least like to have a flavor that works like Maven > > normally > > > > does and for this to be the default. For me this is requisite for > > > > NMaven to be integrated into the Maven project. I realize that there > > > > are shortcomings with the artifact resolution mechanism and using > > RDF > > > > might be good for exploration, but it makes NMaven too divergent > > from > > > > Maven IMO, is confusing to users and really makes NMaven something > > > > different. > > > > > > > > I think you're having a hard enough time getting a community going > > > > and I don't think this fundamental difference in behavior is going > > to > > > > help much in that respect. For me, the three groups I know who are > > > > using it, use both Java and .NET and I always get asked why doesn't > > > > NMaven use POMs like Maven? Will NMaven not currently work without > > > > RDF? And do you really see there being value in being wholly > > > > different with respect to local repository metadata? > > > > > > > > On 30 Sep 07, at 7:57 PM 30 Sep 07, Shane Isbell wrote: > > > > > > > > > Hi Paul, > > > > > > > > > > When NMaven checks for the existence of a file locally, it looks > > in > > > > > the uac > > > > > directory not the repository directory. I am wondering whether the > > > > > meta-data > > > > > in your RDF repo is correct. Can you try: > > > > > > > > > > mvn org.apache.maven.dotnet.plugins:maven-repository- > > > > > plugin:export-rdf > > > > > > > > > > and post the results of the > > > > > .m2/uac/rdfRepository/rdf-repository-export.xmlto a jira? I'll > > take a > > > > > look at it as a starting point to track down the > > > > > problem. > > > > > > > > > > Thanks, > > > > > Shane > > > > > > > > > > > > > > > On 9/28/07, paul anderson <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >> Greetings. Seasoned java/regular maven user here. Now working > > > > >> with .NET . > > > > >> . . . . > > > > >> > > > > >> Building went fine - (had csc and xsd.exe on path). > > > > >> > > > > >> problem came when trying to actually use : mvn compile with a > > valid > > > > >> pom.xml file in the directory > > > > >> (note that I also did not have an nmaven-settings.xml file - not > > sure > > > > >> why): > > > > >> > > > > >> got this (between * for easy parsing): > > > > >> > > > > >> > > ********************************************************************* > > > > >> ************** > > > > >> [INFO] Scanning for projects... > > > > >> [INFO] > > > > >> > > --------------------------------------------------------------------- > > > > >> ------- > > > > >> [INFO] Building Unnamed - snipped:ratecube:library:1.0 > > > > >> [INFO] task-segment: [compile] > > > > >> [INFO] > > > > >> > > --------------------------------------------------------------------- > > > > >> ------- > > > > >> [INFO] [compile:initialize] > > > > >> [INFO] Mojo Execution Time = 0 > > > > >> [INFO] [resolver:resolve] > > > > >> [INFO] > > > > >> > > --------------------------------------------------------------------- > > > > >> --- > > > > >> [ERROR] BUILD ERROR > > > > >> [INFO] > > > > >> > > --------------------------------------------------------------------- > > > > >> --- > > > > >> [INFO] Failed to resolve artifact. > > > > >> > > > > >> Missing: > > > > >> ---------- > > > > >> 1) NMaven.Plugins:NMaven.Plugin.Resx:exe.config:0.14-SNAPSHOT > > > > >> > > > > >> Try downloading the file manually from the project website. > > > > >> > > > > >> Then, install it using the command: > > > > >> mvn install:install-file -DgroupId=NMaven.Plugins-DartifactId= > > > > >> NMaven.Plugin.Resx \ > > > > >> -Dversion= 0.14-SNAPSHOT -Dpackaging=exe.config-Dfile=/ > > > > >> path/to/file > > > > >> > > > > >> > > > > >> > > ********************************************************************* > > > > >> ************************** > > > > >> > > > > >> So, I did just that, where I set /path/tofile = to: > > > > >> > > > > >> C:\Docume~1\<homedir>\.m2\repository\NMaven\Plugins > > > > >> \NMaven.Plugin.Resx\0.14-SNAPSHOT\NMaven.Plugin.Resx.exe > > > > >> > > > > >> Note that I *found* the supposedly not-found resx plugin where it > > was > > > > >> supposed to be. Am I missing > > > > >> something here? > > > > >> > > > > >> Anyway, that generated my nmaven-settings.xml file, and the > > > > >> following mvn > > > > >> compile worked. > > > > >> > > > > >> Hope this helps at least someone - I scratched my head for a day > > > > >> over this > > > > >> one. Oh - I also read > > > > >> the README.txt, and something in there triggered my thinking > > about > > > > >> forcing > > > > >> the install of the file > > > > >> that I knew I had. > > > > >> > > > > >> > > > > >> > > > > >> > > _____________________________________________________________________ > > > > >> _______________ > > > > >> Shape Yahoo! in your own image. Join our Network Research Panel > > > > >> today! > > > > >> http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > > >> > > > > >> > > > > >> > > > > > > > > Thanks, > > > > > > > > Jason > > > > > > > > ---------------------------------------------------------- > > > > Jason van Zyl > > > > Founder, Apache Maven > > > > jason at sonatype dot com > > > > ---------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > >
