Nabble - NMaven

Mailing list is being shut down

2008-12-11T16:57:49Z

Hi,

For those still here, this mailing list is about to be shut down.
Please direct further questions and comments to the projects that
continued development based on the NMaven code:

(trunk) http://www.codeplex.com/nmaven/
(0.14) http://www.codeplex.com/npanday/

Thanks,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

From forum: nmaven-dev

NPanday - Visual Studio Integration for Maven

2008-12-03T03:51:36Z

Hi,

After much consideration, a group of developers from Exist have
started a continuation of the NMaven 0.14 branch at Codeplex under the
project NPanday:

http://www.codeplex.com/npanday

The main objective of the project is to provide Visual Studio
integration for Maven, Maven repositories and to enable command line
builds for .NET projects via Maven.

Those that are using NMaven from that branch should find this much
more stable and fully-featured with a number of the patches applied
and significant work on top to improve the integration.

You can subscribe to the discussion list here: http://www.codeplex.com/npanday/Thread/List.aspx
The source code is available here: https://npanday.svn.codeplex.com/
svn (or browsable through http://www.codeplex.com/npanday/SourceControl/ListDownloadableCommits.aspx)
A release should shortly be available for the convenience of users
that do not wish to build from sources.

The project continues to use the Apache License 2.0 and the Apache
meritocratic model - so contributors are most welcome!

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

From forum: nmaven-dev

NMaven at CodePlex

2008-12-02T11:52:34Z

Just in case there are people on this list who are not on the maven dev
list, I've moved NMaven over to CodePlex: http://www.codeplex.com/nmaven.
CodePlex now has svn support, so it should be an easy switch for most
people: https://nmaven.svn.codeplex.com/svn/trunk. I've incremented the
version to 0.17-SNAPSHOT; that will be the base going forward.

Thanks,
Shane

From forum: nmaven-dev

Re: Dissolving Apache NMaven From ASF Incubator

2008-12-01T22:05:18Z

I'll go ahead and state the obvious. Many of us here really like the
idea of .NET support for maven, but very few of us are willing to
devote the time and resources required to really move the ball
forward. Although I am personally willing to contribute minor
enhancements here and there as my own needs arise, I'm not currently
motivated enough to take on a primary contributor role for NMaven.
Though I may disagree with some of Shane's early architectural
decisions which originally took NMaven away from the maven core, Shane
was actively developing NMaven while I largely sat on the sidelines.
Although their opinions seem to vary a bit, I believe the postings by
Shane and Brett collectively provide a fairly clear summary of why the
project has not gained the level of adoption we would all like.

The harsh reality here is that a few individuals and/or an appropriate
company or funder must step up to the plate or NMaven will die. If
anyone reading this is willing to devote the necessary time to the
project, please consider taking on a more active role. If any
potential funder is willing to commit the funding necessary to
maintain steady progress please indicate a willingness to do so or
otherwise take action to engage appropriate individuals. As with any
software project, good senior talent isn't cheap so any funding
probably needs to at least be in the 6 figure range (USD). Much of
this work will involve enhancements to the maven core, which will
probably be more daunting than a junior engineer can easily handle.

On Dec 1, 2008, at 6:26 PM, Caulene Tibbetts wrote:

> I agree, Christian. We are also a large enterprise using both Java
> and
> .NET, and using a Maven-based build process. The clear benefits of
> using
> NMaven are 1) use of the Archiva repository for binaries, 2)
> versioning
> capability, 3) reproducibility, and 4) consistent tooling throughout
> the
> enterprise. We have been working off the 0.14 branch, but would
> love to
> move over to the trunk as soon as the full functionality is available
> there.
>
> The VS interface has proven to be very valuable to us - it makes it
> easy to
> port an existing project over to NMaven, as well as enabling users
> to use
> NMaven for builds within the IDE. There are a few items which could
> still
> be cleaned up, but the main functionality is there.
>
> The key to increasing adoption of NMaven is letting the .NET world
> know
> about the functionality that is available - I've not been able to find
> *any*other product that addresses versioning, reproducibility, or has
> even a
> vague concept of a binary repository.

Sincerely,
James Carpenter
email: jcarpenter621@...

From forum: nmaven-dev

Re: Dissolving Apache NMaven From ASF Incubator

2008-12-01T16:26:06Z

I agree, Christian. We are also a large enterprise using both Java and
.NET, and using a Maven-based build process. The clear benefits of using
NMaven are 1) use of the Archiva repository for binaries, 2) versioning
capability, 3) reproducibility, and 4) consistent tooling throughout the
enterprise. We have been working off the 0.14 branch, but would love to
move over to the trunk as soon as the full functionality is available
there.

The VS interface has proven to be very valuable to us - it makes it easy to
port an existing project over to NMaven, as well as enabling users to use
NMaven for builds within the IDE. There are a few items which could still
be cleaned up, but the main functionality is there.

The key to increasing adoption of NMaven is letting the .NET world know
about the functionality that is available - I've not been able to find
*any*other product that addresses versioning, reproducibility, or has
even a
vague concept of a binary repository.

From forum: nmaven-dev

Re: How to make manual artifacts using classifiers

2008-11-25T17:28:00Z

I think regardless of what happens next to the code, the same set up
will be required for the NMaven central repository so we should push
forward as planned.

Cheers,
Brett

On 26/11/2008, at 2:15 AM, Christian Raschka wrote:

> I'm against a wait and see tactic. Anyone who is willing to do
> something should be motivated instead of limited.
>
> Maybe we could upload the artifacts to a neutral server?
>
> Christian
>
> On Tue, Nov 25, 2008 at 3:48 PM, Mimil Mimil <mimilowns@...>
> wrote:
>> Hi,
>>
>> so what do we do about nmaven artifacts in central repository as
>> regards the
>> ASF dissolution? Should we wait and see?
>>
>> Regards,
>> Cedric,
>>
>> On Tue, Nov 11, 2008 at 4:54 PM, Mimil Mimil <mimilowns@...>
>> wrote:
>>
>>> Hello everybody,
>>>
>>> I think I will upload to maven central repository the log4net
>>> artifacts I
>>> have created. They are only based on binaries and do not define any
>>> dependencies because I haven't yet succeed to make work
>>> classifiers and
>>> dependencies in the same time.
>>>
>>> Concerning the sources classifier, do we have the jar file format
>>> or there
>>> is a format for dotnet tools?
>>> Concerning the pdb files, it sounds that there is no much support
>>> so I will
>>> wait until I understand how to make them and how to use them in
>>> nmaven/dotnet tools.
>>>
>>> Concerning the help of log4net team to support this artifact, I
>>> think it is
>>> better to wait for the full support of all previous questions.
>>> I hope there will be no problem on the central repository team to
>>> let me
>>> upload these artifacts. Brett, I think it is the same case for you
>>> and
>>> nunit, so could I had you in copy if I have troubles?
>>>
>>> The following files will be uploaded:
>>>
>>>> log4net-1.2.10.0-cli-1.0.dll
>>>> log4net-1.2.10.0-mono-1.0.dll
>>>> log4net-1.2.10.0-mono-2.0.dll
>>>> log4net-1.2.10.0-net-1.0.dll
>>>> log4net-1.2.10.0-net-1.1.dll
>>>> log4net-1.2.10.0-net-2.0.dll
>>>> log4net-1.2.10.0-netcf-1.0.dll
>>>> log4net-1.2.10.0.pom
>>>> log4net-1.2.10.0-sscli-1.0.dll
>>>>
>>>
>>> They have been generated using this script:
>>>
>>>> #!/bin/sh
>>>>
>>>> LOG4NETVERSION=1.2.10.0
>>>> export LOG4NETVERSION
>>>>
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/2.0/release/log4net.dll
>>>> -Dclassifier=net-2.0
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/1.0/release/log4net.dll
>>>> -Dclassifier=net-1.0
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/1.1/release/log4net.dll
>>>> -Dclassifier=net-1.1
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/mono/2.0/release/log4net.dll
>>>> -Dclassifier=mono-2.0
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/mono/1.0/release/log4net.dll
>>>> -Dclassifier=mono-1.0
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/netcf/1.0/release/
>>>> log4net.dll
>>>> -Dclassifier=netcf-1.0
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/cli/1.0/release/log4net.dll
>>>> -Dclassifier=cli-1.0
>>>> mvn install:install-file -DpomFile=pom.xml
>>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/sscli/1.0/release/
>>>> log4net.dll
>>>> -Dclassifier=sscli-1.0
>>>>
>>>> cd ~/.m2/repository/log4net/log4net/$LOG4NETVERSION/
>>>> echo "Bundling local repository files"
>>>> jar -cf log4net-bundle.jar *.dll *.pom
>>>>
>>>
>>> And my pom is:
>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>>>> http://www.w3.org/2001/XMLSchema-instance"
>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>> <modelVersion>4.0.0</modelVersion>
>>>> <groupId>log4net</groupId>
>>>> <artifactId>log4net</artifactId>
>>>> 
>>>> <version>1.2.10.0</version>
>>>> <name>Log for .Net</name>
>>>> <description>log4net is a tool to help the programmer output log
>>>> statements to a variety of output targets.
>>>> </description>
>>>> <url>http://logging.apache.org/log4net/</url>
>>>> <packaging>dotnet:library</packaging>
>>>> <developers>
>>>> <developer>
>>>> <id>mimil</id>
>>>> <email>mimil@...</email>
>>>> <roles>
>>>> <role>artifact creator</role>
>>>> </roles>
>>>> </developer>
>>>> </developers>
>>>> <licenses>
>>>> <license>
>>>> <name>The Apache2 License</name>
>>>> <url>
>>>> http://logging.apache.org/log4net/license.html
>>>> </url>
>>>> </license>
>>>> </licenses>
>>>> <build>
>>>> <finalName>log4net</finalName>
>>>> <plugins>
>>>> 
>>>> <plugin>
>>>> <groupId>org.apache.maven.dotnet.plugins</groupId>
>>>> <artifactId>maven-dotnet-compiler-plugin</
>>>> artifactId>
>>>> 
>>>> <extensions>true</extensions>
>>>> </plugin>
>>>> </plugins>
>>>> </build>
>>>> </project>
>>>>
>>>
>>> Any comments are welcome before I upload them.
>>>
>>> Regards,
>>> Cedric,
>>>
>>>
>>> On Fri, Nov 7, 2008 at 5:03 AM, James Carpenter <jcarpenter621@...
>>> >wrote:
>>>
>>>> You might want to consider adding the pdb and source archives with
>>>> appropriate classifiers along with the assemblies/dlls. Even if
>>>> you don't
>>>> index the pdb files (see below) it will be easy to go back and do
>>>> so later.
>>>>
>>>>
>>>> =======================================
>>>> If you want to go way out of the way you can even add source server
>>>> information to the pdb files.
>>>>
>>>> Lets say you create a maven plugin with the following goal/
>>>> arguments:
>>>>
>>>> prompt>mvn source-server:resolve -DgroupId="com.acme.mortar"
>>>> -DartifactId="tools" -Dversion="1.3.2" -DrelativeFile="tooling/
>>>> trowel.cs"
>>>> -DoutputPath="C:\mysrc\"
>>>>
>>>> The result of this goal would be to resolve the
>>>> com.acme.mortar:tools:sources:1.3.2:jar artifact and extract the
>>>> tooling/trowel.cs file and copy it to
>>>> C:\mysrc\com\acme\mortar\tools\1.3.2\tooling\trowel.cs
>>>>
>>>> You then process the pdb files to inject the magic srcsrv stream
>>>> (see an
>>>> earlier post) which will tell the MS debugging tools for windows
>>>> how to form
>>>> the above command for any of the files used to build the assembly/
>>>> pdb.
>>>>
>>>> The result of this dance will be the ability for the Visual Studio
>>>> debugger to magically step down into the source code of any of the
>>>> assemblies you have placed into the maven repository.
>>>>
>>>> I wrote a post on this mailing list a few weeks ago which gives a
>>>> lot more
>>>> of the details.
>>>>
>>>>
>>>> On Nov 6, 2008, at 3:52 PM, Mimil Mimil wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> As you advised I am making artifacts from binaries because I do
>>>>> not
>>>>> belong
>>>>> to the projects I am doing artifacts - I just want to add more
>>>>> nmaven
>>>>> artifacts for the community.
>>>>>
>>>>> Dependencies will be differents are they are I think related to
>>>>> the
>>>>> environments so I think the only way to manage this is classifier.
>>>>>
>>>>> How the lib differs between environments? I don't have any
>>>>> knowledge of
>>>>> .net
>>>>> but the clearest exemple is for compact framework. As it targets
>>>>> mobiles,
>>>>> pda, ... it is certainly a lot different from the conventional
>>>>> framework.
>>>>> As yes did different DLLs for the different frameworks I think
>>>>> it is
>>>>> because
>>>>> they need it, that's all I can say =)
>>>>>
>>>>> An easy way would be for now to not set dependencies (if we have
>>>>> problem
>>>>> on
>>>>> this point) but is the classifier stuff supported out of the box
>>>>> to
>>>>> deploy
>>>>> manual artifacts? I mean is the namming convention
>>>>> <artifactId>-<version>-<everything else after version is
>>>>> considered as a
>>>>> classifier> ?
>>>>>
>>>>> Do we have to develop a little plugin in order to specify the
>>>>> classifier
>>>>> of
>>>>> artifacts? I say that because the only things I saw through the
>>>>> web as or
>>>>> based on the maven-jar-plugin or on war plugin which I don't
>>>>> remember the
>>>>> name.
>>>>> Maybe http://mojo.codehaus.org/build-helper-maven-plugin/usage.html
>>>>> can
>>>>> be
>>>>> used with attach-artifact?
>>>>>
>>>>> Regards,
>>>>> Cedric,
>>>>>
>>>>> On Thu, Nov 6, 2008 at 7:19 PM, Brett Porter <brett@...>
>>>>> wrote:
>>>>>
>>>>> Yes, you should use classifiers, so the POM you have looks fine
>>>>> (and
>>>>>> there
>>>>>> need be just one). If you are building with NMaven yourself, we
>>>>>> need to
>>>>>> make
>>>>>> sure the compiler plugin supports adding classifiers.
>>>>>>
>>>>>> Profiles shouldn't be needed. If the dependencies differ
>>>>>> between them,
>>>>>> it
>>>>>> might be a problem.
>>>>>>
>>>>>> Is it required to have different versions for each framework?
>>>>>> How do
>>>>>> they
>>>>>> differ exactly?
>>>>>>
>>>>>> Cheers,
>>>>>> Brett
>>>>>>
>>>>>>
>>>>>> On 05/11/2008, at 10:36 AM, Mimil Mimil wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>>
>>>>>>> I am trying to make nmaven artifacts using dll binaries but I
>>>>>>> would
>>>>>>> like
>>>>>>> to
>>>>>>> define the dependencies of this dll.
>>>>>>> In the case of log4net I am currently trying to make I want to
>>>>>>> make
>>>>>>> artifacts for each dotnet environments (dotnet 2.0, dotnet
>>>>>>> 1.1, mono
>>>>>>> ...)
>>>>>>> and I think it should be handled using classifiers.
>>>>>>>
>>>>>>> As for now I think we have to use profiles to define each
>>>>>>> environemnt
>>>>>>> artifacts, by the way I don't know how to use these profiles
>>>>>>> to make
>>>>>>> classifiers.
>>>>>>>
>>>>>>> Here is my current pom with net-1.2 profile and its
>>>>>>> dependencies:
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>
>>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>>>>>>>> http://www.w3.org/2001/XMLSchema-instance"
>>>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>>>>>>
>>>>>>>> <modelVersion>4.0.0</modelVersion>
>>>>>>>> <groupId>log4net</groupId>
>>>>>>>> <artifactId>log4net</artifactId>
>>>>>>>> <version>1.2.10.0-SNAPSHOT</version>
>>>>>>>> <name>Log for .Net</name>
>>>>>>>> <description>log4net is a tool to help the programmer output
>>>>>>>> log
>>>>>>>> statements to a variety of output targets.
>>>>>>>> </description>
>>>>>>>> <url>http://www.xml-rpc.net/</url>
>>>>>>>> <packaging>dotnet:library</packaging>
>>>>>>>>
>>>>>>>>
>>>>>>>> <licenses>
>>>>>>>> <license>
>>>>>>>> <name>The Apache2 License</name>
>>>>>>>> <url>
>>>>>>>> http://logging.apache.org/log4net/license.html
>>>>>>>> </url>
>>>>>>>> </license>
>>>>>>>> </licenses>
>>>>>>>>
>>>>>>>> <build>
>>>>>>>> <finalName>log4net</finalName>
>>>>>>>> 
>>>>>>>> <pluginManagement>
>>>>>>>> <plugins>
>>>>>>>> <plugin>
>>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>>>> <version>2.1</version>
>>>>>>>> </plugin>
>>>>>>>> </plugins>
>>>>>>>> </pluginManagement>
>>>>>>>> 
>>>>>>>> <plugins>
>>>>>>>> <plugin>
>>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>>>> <version>2.1</version>
>>>>>>>> </plugin>
>>>>>>>> </plugins>
>>>>>>>> </build>
>>>>>>>>
>>>>>>>>
>>>>>>>> <profiles>
>>>>>>>> <profile>
>>>>>>>> <id>net-2.0</id>
>>>>>>>>
>>>>>>>> <dependencies>
>>>>>>>> <dependency>
>>>>>>>> <groupId>System.Data</groupId>
>>>>>>>> <artifactId>System.Data</artifactId>
>>>>>>>> <version>2.0.0.0</version>
>>>>>>>> <type>dotnet:gac</type>
>>>>>>>> <scope>system</scope>
>>>>>>>> <classifier>b77a5c561934e089</classifier>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <systemPath>${env.GAC_ROOT}/System.Data/
>>>>>>>> 2.0.0.0__b77a5c561934e089/System.Data.dll</systemPath>
>>>>>>>> </dependency>
>>>>>>>> <dependency>
>>>>>>>> <groupId>System.Web</groupId>
>>>>>>>> <artifactId>System.Web</artifactId>
>>>>>>>> <version>2.0.0.0</version>
>>>>>>>> <type>dotnet:gac</type>
>>>>>>>> <scope>system</scope>
>>>>>>>> <classifier>b03f5f7f11d50a3a</classifier>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> <systemPath>${env.GAC_ROOT}/System.Web/
>>>>>>>> 2.0.0.0__b03f5f7f11d50a3a/System.Web.dll</systemPath>
>>>>>>>> </dependency>
>>>>>>>> </dependencies>
>>>>>>>> </profile>
>>>>>>>> </profiles>
>>>>>>>>
>>>>>>>> </project>
>>>>>>>>
>>>>>>>>
>>>>>>>> Another way to do it is to have a pom by environment and
>>>>>>>> insert the
>>>>>>> classifier name inside the versionId. I remember something about
>>>>>>> versionId
>>>>>>> that must be w.x.y.z, will it be a problem?
>>>>>>>
>>>>>>> I thought to use repository:bundle-pack for the installation in
>>>>>>> repositories
>>>>>>> but I don't know if I have to use this or just a mvn
>>>>>>> deploy:deploy-file
>>>>>>> or...
>>>>>>>
>>>>>>> Any help welcome. I think it will help a lot to have more nmaven
>>>>>>> artifacts
>>>>>>> to have such a thing clear (and documented somewhere).
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Regards,
>>>>>>> Cédric,
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Brett Porter
>>>>>> brett@...
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>>
>>>> Sincerely,
>>>> James Carpenter
>>>> cell: 832-677-7247
>>>> email: jcarpenter621@...
>>>>
>>>>
>>>>
>>>>
>>>
>>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

From forum: nmaven-dev

Re: How to make manual artifacts using classifiers

2008-11-25T07:15:46Z

I'm against a wait and see tactic. Anyone who is willing to do
something should be motivated instead of limited.

Maybe we could upload the artifacts to a neutral server?

Christian

On Tue, Nov 25, 2008 at 3:48 PM, Mimil Mimil <mimilowns@...> wrote:

> Hi,
>
> so what do we do about nmaven artifacts in central repository as regards the
> ASF dissolution? Should we wait and see?
>
> Regards,
> Cedric,
>
> On Tue, Nov 11, 2008 at 4:54 PM, Mimil Mimil <mimilowns@...> wrote:
>
>> Hello everybody,
>>
>> I think I will upload to maven central repository the log4net artifacts I
>> have created. They are only based on binaries and do not define any
>> dependencies because I haven't yet succeed to make work classifiers and
>> dependencies in the same time.
>>
>> Concerning the sources classifier, do we have the jar file format or there
>> is a format for dotnet tools?
>> Concerning the pdb files, it sounds that there is no much support so I will
>> wait until I understand how to make them and how to use them in
>> nmaven/dotnet tools.
>>
>> Concerning the help of log4net team to support this artifact, I think it is
>> better to wait for the full support of all previous questions.
>> I hope there will be no problem on the central repository team to let me
>> upload these artifacts. Brett, I think it is the same case for you and
>> nunit, so could I had you in copy if I have troubles?
>>
>> The following files will be uploaded:
>>
>>> log4net-1.2.10.0-cli-1.0.dll
>>> log4net-1.2.10.0-mono-1.0.dll
>>> log4net-1.2.10.0-mono-2.0.dll
>>> log4net-1.2.10.0-net-1.0.dll
>>> log4net-1.2.10.0-net-1.1.dll
>>> log4net-1.2.10.0-net-2.0.dll
>>> log4net-1.2.10.0-netcf-1.0.dll
>>> log4net-1.2.10.0.pom
>>> log4net-1.2.10.0-sscli-1.0.dll
>>>
>>
>> They have been generated using this script:
>>
>>> #!/bin/sh
>>>
>>> LOG4NETVERSION=1.2.10.0
>>> export LOG4NETVERSION
>>>
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/2.0/release/log4net.dll
>>> -Dclassifier=net-2.0
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/1.0/release/log4net.dll
>>> -Dclassifier=net-1.0
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/1.1/release/log4net.dll
>>> -Dclassifier=net-1.1
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/mono/2.0/release/log4net.dll
>>> -Dclassifier=mono-2.0
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/mono/1.0/release/log4net.dll
>>> -Dclassifier=mono-1.0
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/netcf/1.0/release/log4net.dll
>>> -Dclassifier=netcf-1.0
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/cli/1.0/release/log4net.dll
>>> -Dclassifier=cli-1.0
>>> mvn install:install-file -DpomFile=pom.xml
>>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/sscli/1.0/release/log4net.dll
>>> -Dclassifier=sscli-1.0
>>>
>>> cd ~/.m2/repository/log4net/log4net/$LOG4NETVERSION/
>>> echo "Bundling local repository files"
>>> jar -cf log4net-bundle.jar *.dll *.pom
>>>
>>
>> And my pom is:
>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>>> http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>> <modelVersion>4.0.0</modelVersion>
>>> <groupId>log4net</groupId>
>>> <artifactId>log4net</artifactId>
>>> 
>>> <version>1.2.10.0</version>
>>> <name>Log for .Net</name>
>>> <description>log4net is a tool to help the programmer output log
>>> statements to a variety of output targets.
>>> </description>
>>> <url>http://logging.apache.org/log4net/</url>
>>> <packaging>dotnet:library</packaging>
>>> <developers>
>>> <developer>
>>> <id>mimil</id>
>>> <email>mimil@...</email>
>>> <roles>
>>> <role>artifact creator</role>
>>> </roles>
>>> </developer>
>>> </developers>
>>> <licenses>
>>> <license>
>>> <name>The Apache2 License</name>
>>> <url>
>>> http://logging.apache.org/log4net/license.html
>>> </url>
>>> </license>
>>> </licenses>
>>> <build>
>>> <finalName>log4net</finalName>
>>> <plugins>
>>> 
>>> <plugin>
>>> <groupId>org.apache.maven.dotnet.plugins</groupId>
>>> <artifactId>maven-dotnet-compiler-plugin</artifactId>
>>> 
>>> <extensions>true</extensions>
>>> </plugin>
>>> </plugins>
>>> </build>
>>> </project>
>>>
>>
>> Any comments are welcome before I upload them.
>>
>> Regards,
>> Cedric,
>>
>>
>> On Fri, Nov 7, 2008 at 5:03 AM, James Carpenter <jcarpenter621@...>wrote:
>>
>>> You might want to consider adding the pdb and source archives with
>>> appropriate classifiers along with the assemblies/dlls. Even if you don't
>>> index the pdb files (see below) it will be easy to go back and do so later.
>>>
>>>
>>> =======================================
>>> If you want to go way out of the way you can even add source server
>>> information to the pdb files.
>>>
>>> Lets say you create a maven plugin with the following goal/arguments:
>>>
>>> prompt>mvn source-server:resolve -DgroupId="com.acme.mortar"
>>> -DartifactId="tools" -Dversion="1.3.2" -DrelativeFile="tooling/trowel.cs"
>>> -DoutputPath="C:\mysrc\"
>>>
>>> The result of this goal would be to resolve the
>>> com.acme.mortar:tools:sources:1.3.2:jar artifact and extract the
>>> tooling/trowel.cs file and copy it to
>>> C:\mysrc\com\acme\mortar\tools\1.3.2\tooling\trowel.cs
>>>
>>> You then process the pdb files to inject the magic srcsrv stream (see an
>>> earlier post) which will tell the MS debugging tools for windows how to form
>>> the above command for any of the files used to build the assembly/pdb.
>>>
>>> The result of this dance will be the ability for the Visual Studio
>>> debugger to magically step down into the source code of any of the
>>> assemblies you have placed into the maven repository.
>>>
>>> I wrote a post on this mailing list a few weeks ago which gives a lot more
>>> of the details.
>>>
>>>
>>> On Nov 6, 2008, at 3:52 PM, Mimil Mimil wrote:
>>>
>>> Hi,
>>>>
>>>> As you advised I am making artifacts from binaries because I do not
>>>> belong
>>>> to the projects I am doing artifacts - I just want to add more nmaven
>>>> artifacts for the community.
>>>>
>>>> Dependencies will be differents are they are I think related to the
>>>> environments so I think the only way to manage this is classifier.
>>>>
>>>> How the lib differs between environments? I don't have any knowledge of
>>>> .net
>>>> but the clearest exemple is for compact framework. As it targets mobiles,
>>>> pda, ... it is certainly a lot different from the conventional framework.
>>>> As yes did different DLLs for the different frameworks I think it is
>>>> because
>>>> they need it, that's all I can say =)
>>>>
>>>> An easy way would be for now to not set dependencies (if we have problem
>>>> on
>>>> this point) but is the classifier stuff supported out of the box to
>>>> deploy
>>>> manual artifacts? I mean is the namming convention
>>>> <artifactId>-<version>-<everything else after version is considered as a
>>>> classifier> ?
>>>>
>>>> Do we have to develop a little plugin in order to specify the classifier
>>>> of
>>>> artifacts? I say that because the only things I saw through the web as or
>>>> based on the maven-jar-plugin or on war plugin which I don't remember the
>>>> name.
>>>> Maybe http://mojo.codehaus.org/build-helper-maven-plugin/usage.html can
>>>> be
>>>> used with attach-artifact?
>>>>
>>>> Regards,
>>>> Cedric,
>>>>
>>>> On Thu, Nov 6, 2008 at 7:19 PM, Brett Porter <brett@...> wrote:
>>>>
>>>> Yes, you should use classifiers, so the POM you have looks fine (and
>>>>> there
>>>>> need be just one). If you are building with NMaven yourself, we need to
>>>>> make
>>>>> sure the compiler plugin supports adding classifiers.
>>>>>
>>>>> Profiles shouldn't be needed. If the dependencies differ between them,
>>>>> it
>>>>> might be a problem.
>>>>>
>>>>> Is it required to have different versions for each framework? How do
>>>>> they
>>>>> differ exactly?
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>>
>>>>> On 05/11/2008, at 10:36 AM, Mimil Mimil wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>>>
>>>>>> I am trying to make nmaven artifacts using dll binaries but I would
>>>>>> like
>>>>>> to
>>>>>> define the dependencies of this dll.
>>>>>> In the case of log4net I am currently trying to make I want to make
>>>>>> artifacts for each dotnet environments (dotnet 2.0, dotnet 1.1, mono
>>>>>> ...)
>>>>>> and I think it should be handled using classifiers.
>>>>>>
>>>>>> As for now I think we have to use profiles to define each environemnt
>>>>>> artifacts, by the way I don't know how to use these profiles to make
>>>>>> classifiers.
>>>>>>
>>>>>> Here is my current pom with net-1.2 profile and its dependencies:
>>>>>>
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>
>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>>>>>>> http://www.w3.org/2001/XMLSchema-instance"
>>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>>>>>
>>>>>>> <modelVersion>4.0.0</modelVersion>
>>>>>>> <groupId>log4net</groupId>
>>>>>>> <artifactId>log4net</artifactId>
>>>>>>> <version>1.2.10.0-SNAPSHOT</version>
>>>>>>> <name>Log for .Net</name>
>>>>>>> <description>log4net is a tool to help the programmer output log
>>>>>>> statements to a variety of output targets.
>>>>>>> </description>
>>>>>>> <url>http://www.xml-rpc.net/</url>
>>>>>>> <packaging>dotnet:library</packaging>
>>>>>>>
>>>>>>>
>>>>>>> <licenses>
>>>>>>> <license>
>>>>>>> <name>The Apache2 License</name>
>>>>>>> <url>
>>>>>>> http://logging.apache.org/log4net/license.html
>>>>>>> </url>
>>>>>>> </license>
>>>>>>> </licenses>
>>>>>>>
>>>>>>> <build>
>>>>>>> <finalName>log4net</finalName>
>>>>>>> 
>>>>>>> <pluginManagement>
>>>>>>> <plugins>
>>>>>>> <plugin>
>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>>> <version>2.1</version>
>>>>>>> </plugin>
>>>>>>> </plugins>
>>>>>>> </pluginManagement>
>>>>>>> 
>>>>>>> <plugins>
>>>>>>> <plugin>
>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>>> <version>2.1</version>
>>>>>>> </plugin>
>>>>>>> </plugins>
>>>>>>> </build>
>>>>>>>
>>>>>>>
>>>>>>> <profiles>
>>>>>>> <profile>
>>>>>>> <id>net-2.0</id>
>>>>>>>
>>>>>>> <dependencies>
>>>>>>> <dependency>
>>>>>>> <groupId>System.Data</groupId>
>>>>>>> <artifactId>System.Data</artifactId>
>>>>>>> <version>2.0.0.0</version>
>>>>>>> <type>dotnet:gac</type>
>>>>>>> <scope>system</scope>
>>>>>>> <classifier>b77a5c561934e089</classifier>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <systemPath>${env.GAC_ROOT}/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll</systemPath>
>>>>>>> </dependency>
>>>>>>> <dependency>
>>>>>>> <groupId>System.Web</groupId>
>>>>>>> <artifactId>System.Web</artifactId>
>>>>>>> <version>2.0.0.0</version>
>>>>>>> <type>dotnet:gac</type>
>>>>>>> <scope>system</scope>
>>>>>>> <classifier>b03f5f7f11d50a3a</classifier>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <systemPath>${env.GAC_ROOT}/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll</systemPath>
>>>>>>> </dependency>
>>>>>>> </dependencies>
>>>>>>> </profile>
>>>>>>> </profiles>
>>>>>>>
>>>>>>> </project>
>>>>>>>
>>>>>>>
>>>>>>> Another way to do it is to have a pom by environment and insert the
>>>>>> classifier name inside the versionId. I remember something about
>>>>>> versionId
>>>>>> that must be w.x.y.z, will it be a problem?
>>>>>>
>>>>>> I thought to use repository:bundle-pack for the installation in
>>>>>> repositories
>>>>>> but I don't know if I have to use this or just a mvn deploy:deploy-file
>>>>>> or...
>>>>>>
>>>>>> Any help welcome. I think it will help a lot to have more nmaven
>>>>>> artifacts
>>>>>> to have such a thing clear (and documented somewhere).
>>>>>> Thanks,
>>>>>>
>>>>>> Regards,
>>>>>> Cédric,
>>>>>>
>>>>>>
>>>>> --
>>>>> Brett Porter
>>>>> brett@...
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>>
>>> Sincerely,
>>> James Carpenter
>>> cell: 832-677-7247
>>> email: jcarpenter621@...
>>>
>>>
>>>
>>>
>>
>

From forum: nmaven-dev

Re: How to make manual artifacts using classifiers

2008-11-25T06:48:03Z

Hi,

so what do we do about nmaven artifacts in central repository as regards the
ASF dissolution? Should we wait and see?

Regards,
Cedric,

On Tue, Nov 11, 2008 at 4:54 PM, Mimil Mimil <mimilowns@...> wrote:

> Hello everybody,
>
> I think I will upload to maven central repository the log4net artifacts I
> have created. They are only based on binaries and do not define any
> dependencies because I haven't yet succeed to make work classifiers and
> dependencies in the same time.
>
> Concerning the sources classifier, do we have the jar file format or there
> is a format for dotnet tools?
> Concerning the pdb files, it sounds that there is no much support so I will
> wait until I understand how to make them and how to use them in
> nmaven/dotnet tools.
>
> Concerning the help of log4net team to support this artifact, I think it is
> better to wait for the full support of all previous questions.
> I hope there will be no problem on the central repository team to let me
> upload these artifacts. Brett, I think it is the same case for you and
> nunit, so could I had you in copy if I have troubles?
>
> The following files will be uploaded:
>
>> log4net-1.2.10.0-cli-1.0.dll
>> log4net-1.2.10.0-mono-1.0.dll
>> log4net-1.2.10.0-mono-2.0.dll
>> log4net-1.2.10.0-net-1.0.dll
>> log4net-1.2.10.0-net-1.1.dll
>> log4net-1.2.10.0-net-2.0.dll
>> log4net-1.2.10.0-netcf-1.0.dll
>> log4net-1.2.10.0.pom
>> log4net-1.2.10.0-sscli-1.0.dll
>>
>
> They have been generated using this script:
>
>> #!/bin/sh
>>
>> LOG4NETVERSION=1.2.10.0
>> export LOG4NETVERSION
>>
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/2.0/release/log4net.dll
>> -Dclassifier=net-2.0
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/1.0/release/log4net.dll
>> -Dclassifier=net-1.0
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/net/1.1/release/log4net.dll
>> -Dclassifier=net-1.1
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/mono/2.0/release/log4net.dll
>> -Dclassifier=mono-2.0
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/mono/1.0/release/log4net.dll
>> -Dclassifier=mono-1.0
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/netcf/1.0/release/log4net.dll
>> -Dclassifier=netcf-1.0
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/cli/1.0/release/log4net.dll
>> -Dclassifier=cli-1.0
>> mvn install:install-file -DpomFile=pom.xml
>> -Dfile=lib/log4net-$LOG4NETVERSION/bin/sscli/1.0/release/log4net.dll
>> -Dclassifier=sscli-1.0
>>
>> cd ~/.m2/repository/log4net/log4net/$LOG4NETVERSION/
>> echo "Bundling local repository files"
>> jar -cf log4net-bundle.jar *.dll *.pom
>>
>
> And my pom is:
>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>> <modelVersion>4.0.0</modelVersion>
>> <groupId>log4net</groupId>
>> <artifactId>log4net</artifactId>
>> 
>> <version>1.2.10.0</version>
>> <name>Log for .Net</name>
>> <description>log4net is a tool to help the programmer output log
>> statements to a variety of output targets.
>> </description>
>> <url>http://logging.apache.org/log4net/</url>
>> <packaging>dotnet:library</packaging>
>> <developers>
>> <developer>
>> <id>mimil</id>
>> <email>mimil@...</email>
>> <roles>
>> <role>artifact creator</role>
>> </roles>
>> </developer>
>> </developers>
>> <licenses>
>> <license>
>> <name>The Apache2 License</name>
>> <url>
>> http://logging.apache.org/log4net/license.html
>> </url>
>> </license>
>> </licenses>
>> <build>
>> <finalName>log4net</finalName>
>> <plugins>
>> 
>> <plugin>
>> <groupId>org.apache.maven.dotnet.plugins</groupId>
>> <artifactId>maven-dotnet-compiler-plugin</artifactId>
>> 
>> <extensions>true</extensions>
>> </plugin>
>> </plugins>
>> </build>
>> </project>
>>
>
> Any comments are welcome before I upload them.
>
> Regards,
> Cedric,
>
>
> On Fri, Nov 7, 2008 at 5:03 AM, James Carpenter <jcarpenter621@...>wrote:
>
>> You might want to consider adding the pdb and source archives with
>> appropriate classifiers along with the assemblies/dlls. Even if you don't
>> index the pdb files (see below) it will be easy to go back and do so later.
>>
>>
>> =======================================
>> If you want to go way out of the way you can even add source server
>> information to the pdb files.
>>
>> Lets say you create a maven plugin with the following goal/arguments:
>>
>> prompt>mvn source-server:resolve -DgroupId="com.acme.mortar"
>> -DartifactId="tools" -Dversion="1.3.2" -DrelativeFile="tooling/trowel.cs"
>> -DoutputPath="C:\mysrc\"
>>
>> The result of this goal would be to resolve the
>> com.acme.mortar:tools:sources:1.3.2:jar artifact and extract the
>> tooling/trowel.cs file and copy it to
>> C:\mysrc\com\acme\mortar\tools\1.3.2\tooling\trowel.cs
>>
>> You then process the pdb files to inject the magic srcsrv stream (see an
>> earlier post) which will tell the MS debugging tools for windows how to form
>> the above command for any of the files used to build the assembly/pdb.
>>
>> The result of this dance will be the ability for the Visual Studio
>> debugger to magically step down into the source code of any of the
>> assemblies you have placed into the maven repository.
>>
>> I wrote a post on this mailing list a few weeks ago which gives a lot more
>> of the details.
>>
>>
>> On Nov 6, 2008, at 3:52 PM, Mimil Mimil wrote:
>>
>> Hi,
>>>
>>> As you advised I am making artifacts from binaries because I do not
>>> belong
>>> to the projects I am doing artifacts - I just want to add more nmaven
>>> artifacts for the community.
>>>
>>> Dependencies will be differents are they are I think related to the
>>> environments so I think the only way to manage this is classifier.
>>>
>>> How the lib differs between environments? I don't have any knowledge of
>>> .net
>>> but the clearest exemple is for compact framework. As it targets mobiles,
>>> pda, ... it is certainly a lot different from the conventional framework.
>>> As yes did different DLLs for the different frameworks I think it is
>>> because
>>> they need it, that's all I can say =)
>>>
>>> An easy way would be for now to not set dependencies (if we have problem
>>> on
>>> this point) but is the classifier stuff supported out of the box to
>>> deploy
>>> manual artifacts? I mean is the namming convention
>>> <artifactId>-<version>-<everything else after version is considered as a
>>> classifier> ?
>>>
>>> Do we have to develop a little plugin in order to specify the classifier
>>> of
>>> artifacts? I say that because the only things I saw through the web as or
>>> based on the maven-jar-plugin or on war plugin which I don't remember the
>>> name.
>>> Maybe http://mojo.codehaus.org/build-helper-maven-plugin/usage.html can
>>> be
>>> used with attach-artifact?
>>>
>>> Regards,
>>> Cedric,
>>>
>>> On Thu, Nov 6, 2008 at 7:19 PM, Brett Porter <brett@...> wrote:
>>>
>>> Yes, you should use classifiers, so the POM you have looks fine (and
>>>> there
>>>> need be just one). If you are building with NMaven yourself, we need to
>>>> make
>>>> sure the compiler plugin supports adding classifiers.
>>>>
>>>> Profiles shouldn't be needed. If the dependencies differ between them,
>>>> it
>>>> might be a problem.
>>>>
>>>> Is it required to have different versions for each framework? How do
>>>> they
>>>> differ exactly?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>>
>>>> On 05/11/2008, at 10:36 AM, Mimil Mimil wrote:
>>>>
>>>> Hello,
>>>>
>>>>>
>>>>> I am trying to make nmaven artifacts using dll binaries but I would
>>>>> like
>>>>> to
>>>>> define the dependencies of this dll.
>>>>> In the case of log4net I am currently trying to make I want to make
>>>>> artifacts for each dotnet environments (dotnet 2.0, dotnet 1.1, mono
>>>>> ...)
>>>>> and I think it should be handled using classifiers.
>>>>>
>>>>> As for now I think we have to use profiles to define each environemnt
>>>>> artifacts, by the way I don't know how to use these profiles to make
>>>>> classifiers.
>>>>>
>>>>> Here is my current pom with net-1.2 profile and its dependencies:
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>
>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>>>>>> http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>>>>
>>>>>> <modelVersion>4.0.0</modelVersion>
>>>>>> <groupId>log4net</groupId>
>>>>>> <artifactId>log4net</artifactId>
>>>>>> <version>1.2.10.0-SNAPSHOT</version>
>>>>>> <name>Log for .Net</name>
>>>>>> <description>log4net is a tool to help the programmer output log
>>>>>> statements to a variety of output targets.
>>>>>> </description>
>>>>>> <url>http://www.xml-rpc.net/</url>
>>>>>> <packaging>dotnet:library</packaging>
>>>>>>
>>>>>>
>>>>>> <licenses>
>>>>>> <license>
>>>>>> <name>The Apache2 License</name>
>>>>>> <url>
>>>>>> http://logging.apache.org/log4net/license.html
>>>>>> </url>
>>>>>> </license>
>>>>>> </licenses>
>>>>>>
>>>>>> <build>
>>>>>> <finalName>log4net</finalName>
>>>>>> 
>>>>>> <pluginManagement>
>>>>>> <plugins>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>> <version>2.1</version>
>>>>>> </plugin>
>>>>>> </plugins>
>>>>>> </pluginManagement>
>>>>>> 
>>>>>> <plugins>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>> <version>2.1</version>
>>>>>> </plugin>
>>>>>> </plugins>
>>>>>> </build>
>>>>>>
>>>>>>
>>>>>> <profiles>
>>>>>> <profile>
>>>>>> <id>net-2.0</id>
>>>>>>
>>>>>> <dependencies>
>>>>>> <dependency>
>>>>>> <groupId>System.Data</groupId>
>>>>>> <artifactId>System.Data</artifactId>
>>>>>> <version>2.0.0.0</version>
>>>>>> <type>dotnet:gac</type>
>>>>>> <scope>system</scope>
>>>>>> <classifier>b77a5c561934e089</classifier>
>>>>>>
>>>>>>
>>>>>>
>>>>>> <systemPath>${env.GAC_ROOT}/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll</systemPath>
>>>>>> </dependency>
>>>>>> <dependency>
>>>>>> <groupId>System.Web</groupId>
>>>>>> <artifactId>System.Web</artifactId>
>>>>>> <version>2.0.0.0</version>
>>>>>> <type>dotnet:gac</type>
>>>>>> <scope>system</scope>
>>>>>> <classifier>b03f5f7f11d50a3a</classifier>
>>>>>>
>>>>>>
>>>>>>
>>>>>> <systemPath>${env.GAC_ROOT}/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll</systemPath>
>>>>>> </dependency>
>>>>>> </dependencies>
>>>>>> </profile>
>>>>>> </profiles>
>>>>>>
>>>>>> </project>
>>>>>>
>>>>>>
>>>>>> Another way to do it is to have a pom by environment and insert the
>>>>> classifier name inside the versionId. I remember something about
>>>>> versionId
>>>>> that must be w.x.y.z, will it be a problem?
>>>>>
>>>>> I thought to use repository:bundle-pack for the installation in
>>>>> repositories
>>>>> but I don't know if I have to use this or just a mvn deploy:deploy-file
>>>>> or...
>>>>>
>>>>> Any help welcome. I think it will help a lot to have more nmaven
>>>>> artifacts
>>>>> to have such a thing clear (and documented somewhere).
>>>>> Thanks,
>>>>>
>>>>> Regards,
>>>>> Cédric,
>>>>>
>>>>>
>>>> --
>>>> Brett Porter
>>>> brett@...
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
>> Sincerely,
>> James Carpenter
>> cell: 832-677-7247
>> email: jcarpenter621@...
>>
>>
>>
>>
>

From forum: nmaven-dev

Re: Dissolving Apache NMaven From ASF Incubator

2008-11-21T07:51:11Z

I want to drop some thoughts into the discussion. We are a shop using
both Java and .Net. I am using Maven for all my projects and having a
build process which is based on Maven. Beside the well know benefits
of Maven, a big point for using it, is the versioning and
reproducibility. We have products and components which you could
easily put together in different versions. Maven (and the Archiva
Repository Server we use) helps us at this point.

Now I have seen NMaven and I tried to port the ideas of the Java World
to the .net one. At this point I have seen the (mentioned) problems
Maven has (for the .Net world). I also would like to help to NMaven
community, because I like the project very much, but it is very
confusing where to start. (There is a release (0.14) which seems to be
used, but for me it doesn't work. And there is the trunk, which I
think needs much work to be done, e.g. it seems important to have a VS
Plugin to generate solutions out of poms and vice versa.)

And thats the point. I don't know how a migration could solve this issue.

I also think, that you could use the help of the maven developer, if
there are problems, but I don't know how this was in the history.

I don't know how much maven related things could be reused by NMaven,
but I think reusing code is better as developing new things in an
other language. I think we should go out to the .net community and
show them what the benefits of NMaven are instead of simply
capitulating. I haven't seen something simular to maven in the .net
world.

In the next days I will talk to some german alt.net guys and see what
there opinion is.

From forum: nmaven-dev

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-wix-plugin - default maven2 buildDefinition

2008-11-19T21:43:57Z

Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=125761&projectId=1245

Build statistics:
State: Ok
Previous State: Error
Started at: Wed 19 Nov 2008 21:43:29 -0800
Finished at: Wed 19 Nov 2008 21:43:52 -0800
Total time: 22s
Build Trigger: Schedule
Build Number: 27
Exit code: 0
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)

Builder version :
Maven version: 2.0.9
Java version: 1.5.0_12
OS name: "linux" version: "2.6.20-16-server" arch: "i386" Family: "unix"

****************************************************************************
SCM Changes:
****************************************************************************
No files changed

****************************************************************************
Dependencies Changes:
****************************************************************************
org.apache.maven.dotnet:maven-dotnet-core:0.16-incubating-SNAPSHOT

org.apache.maven.dotnet:maven-dotnet-plugin-api:0.16-incubating-SNAPSHOT

org.apache.maven.dotnet:maven-dotnet-toolchain:0.16-incubating-SNAPSHOT

org.apache.maven.dotnet.plugins:maven-dotnet-plugins:0.16-incubating-SNAPSHOT

****************************************************************************
Build Definition:
****************************************************************************
POM filename: pom.xml
Goals: clean install
Arguments: --batch-mode --non-recursive
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: Maven 2.0.9, Java 5
Description: default maven2 buildDefinition

****************************************************************************
Test Summary:
****************************************************************************
Tests: 0
Failures: 0
Total time: 0.0

Nabble - NMaven

Mailing list is being shut down

NPanday - Visual Studio Integration for Maven

NMaven at CodePlex

Re: Dissolving Apache NMaven From ASF Incubator

Re: Dissolving Apache NMaven From ASF Incubator

Re: How to make manual artifacts using classifiers

Re: How to make manual artifacts using classifiers

Re: How to make manual artifacts using classifiers

Re: Dissolving Apache NMaven From ASF Incubator

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-wix-plugin - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-toolchain - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-test-plugin - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-plugins - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-plugin-api - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-parent - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-extensions - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-core-it-runner - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-core - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-components - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-compiler-plugin - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-compiler - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-dotnet-assembler - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-archetype-dotnet-windows-control - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-archetype-dotnet-windows-application - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-archetype-dotnet-console-application - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: maven-archetype-dotnet-class-library - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: dotnet-archetypes - default maven2 buildDefinition

[continuum] BUILD SUCCESSFUL: NMaven - Apache NMaven: core-integration-tests - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-wix-plugin - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-toolchain - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-test-plugin - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-plugins - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-plugin-api - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-parent - default maven2 buildDefinition

[continuum] BUILD ERROR: NMaven - Apache NMaven: maven-dotnet-extensions - default maven2 buildDefinition