You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by Jason van Zyl <ja...@maven.org> on 2007/10/15 05:35:10 UTC
NMaven not using POMs in local repository
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 <pa...@yahoo.com> 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
----------------------------------------------------------
Re: NMaven not using POMs in local repository
Posted by Shane Isbell <sh...@gmail.com>.
Anybody have problems with requiring versions in the filename/assemblyname?
On 10/15/07, Shane Isbell <sh...@gmail.com> 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 <ev...@gmail.com> 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 < shane.isbell@gmail.com> 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 < jason@maven.org> 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 <pa...@yahoo.com> 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
> > > > ----------------------------------------------------------
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
Re: NMaven not using POMs in local repository
Posted by Shane Isbell <sh...@gmail.com>.
Anybody have problems with requiring versions in the filename/assemblyname?
On 10/15/07, Shane Isbell <sh...@gmail.com> 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 <ev...@gmail.com> 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 < shane.isbell@gmail.com> 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 < jason@maven.org> 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 <pa...@yahoo.com> 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
> > > > ----------------------------------------------------------
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
Re: NMaven not using POMs in local repository
Posted by Shane Isbell <sh...@gmail.com>.
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 <ev...@gmail.com> 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 <sh...@gmail.com> 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 <ja...@maven.org> 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 <pa...@yahoo.com> 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
> > > ----------------------------------------------------------
> > >
> > >
> > >
> > >
> >
>
Re: NMaven not using POMs in local repository
Posted by Evan Worley <ev...@gmail.com>.
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 <sh...@gmail.com> 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 <ja...@maven.org> 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 <pa...@yahoo.com> 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
> > ----------------------------------------------------------
> >
> >
> >
> >
>
Re: NMaven not using POMs in local repository
Posted by Shane Isbell <sh...@gmail.com>.
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 <ja...@maven.org> 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 <pa...@yahoo.com> 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
> ----------------------------------------------------------
>
>
>
>