Nabble - nmaven-dev

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/

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/

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

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@...

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.

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/

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@...
>>>
>>>
>>>
>>>
>>
>

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@...
>>
>>
>>
>>
>

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.

Re: mvn test

2008-11-19T17:13:47Z

I think I found a bug:
with this in my pom.xml

<dependency>
<groupId>it.unibo.deis.EsameIS</groupId>
<artifactId>MyLib</artifactId>
<version>1.0</version>
<classifier>test</classifier>
<scope>test</scope>
<type>dotnet:library</type>
</dependency>

the compiler compiles well the code, but can't execute the test
because in the directory test-assemblies there's no file
MyLib-1.0-test.dll

the thing that happens is that I find MyLib-1.0.dll instead of the
test library! In the project there are no other MyLib deps

Re: mvn test

2008-11-19T16:50:48Z

Right... this seems a deciciency in the nmaven packaging plugins that
exist today. However, I believe they do create the test DLL, so you
could use the build helper plugin in the original project to attach
that to the build and have it installed for the other.

Cheers,
Brett

On 20/11/2008, at 10:57 AM, Nicolò Chieffo wrote:

> this is a page related to maven
> http://maven.apache.org/guides/mini/guide-attached-tests.html
>
> but we don't use maven-jar-plugin right?

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

Re: mvn test

2008-11-19T15:57:12Z

this is a page related to maven
http://maven.apache.org/guides/mini/guide-attached-tests.html

but we don't use maven-jar-plugin right?

mvn test

2008-11-19T08:50:53Z

Hello, I've build an application which depends on a library.
The tests in the application also depends on the test which are in the
library (they are implementation of abstract tests)

when I run mvn test I get an error message saying that nunit-console failed:
[INFO] ** (/usr/lib/nunit/nunit-console.exe:3579): WARNING **: The
following assembly referenced from
/home/yelo3/EsameIS/RemotingNetworkServices/target/test-assemblies/RemotingNetworkServices-1.0-test.dll
could not be loaded:

the test compiles, so the pom.xml is correct for compilation,
the problem is that nunit-console needs the mylib-1.0-test.dll in the path:
in fact in the directory test-assemblies there is only mylib-1.0.dll

how can I format pom.xml to copy the test assemblies of the mylib
dependency in test-assemblies?

I have this:
<dependency>
<groupId>it.unibo.deis.EsameIS</groupId>
<artifactId>MyLib</artifactId>
<version>1.0</version>
<classifier>test</classifier>
<scope>test</scope>
<type>dotnet:library</type>
</dependency>

Thanks

Re: Dissolving Apache NMaven From ASF Incubator

2008-11-17T06:29:52Z

On 17-Nov-08, at 8:29 AM, Brett Porter wrote:

> I have a number of perspectives on this, and have taken the time
> traveling over the last few days to reflect on this decision.
>
> As a mentor, I can recognise the podling in its current form is not
> working. Contributions, patches, and questions have gone largely
> ignored this year, and development stalled after the migration to a
> new trunk. For a long time we have assumed that a kick in that
> direction was all that was needed to get it going again, but only
> small steps have been taken. Something clearly needs to change.
>
> I don't believe the move you've suggested will make visibility,
> community involvement and a steady release schedule any more likely
> than it is now - they simply require a conscious decision and group
> effort to do so which could equally be achieved here.
>

All we know is that here did not work. All Shane wants to do is try a
different approach.

> My primary role in the project at the moment is as a user,
> distributor and occasional developer. There are two reasons your
> proposal won't satisfy our needs in that regard:
> - we are committed to and required to maintain the code in an
> independent environment
> - we require integration with Archiva for the search and management
> functionality
>
> Do you have some alternative proposition here? I realise these may
> not be your personal "itches", but there are no technical reasons
> they can't be achieved by other community members that are
> interested in doing so while other work continues in the areas
> you've described.
>
> I personally agree with the overarching technical direction you've
> described. In the long term, I see the .NET portions of this project
> doing much of the work independently, and this is also consistent
> with discussions I've had with others. However, Byldan hadn't seemed
> much more than an experiment to date - could you elaborate on where
> you think it stands to be able to provide a solution to Maven users
> today, or what kind of effort is required to bring it to that point?
>

NMaven is useful for people who have hybrid approach: Java on the back-
end and .NET in the front-end. Byldan would be a pure .NET approach
for Microsoft developers who are looking for an analog to Maven
without the requirement of a Java runtime. For a shop that is already
doing Java it's not a big stretch to use Java intermixed with C#. But
for shops doing purely .NET I have found interest in NMaven to be
slight at best. They are almost immediately turned off by having to
install Java anything. Looking at your typical developer using
Codeplex this is the profile that you have. They don't know anything
about Java and don't want to know anything about Java. So NMaven
provides the solution for the hybrid shop, Byldan is for a whole new
and different user base. An attempt to bring a new set of users into a
Maven way of developing software.

> I would still urge you to reconsider and give a renewed effort here
> to see what we can achieve by openly discussing the issues and
> roadmap for everyone that is interested in this project and seeing
> what comes of it.
>

The majority of the IPMC members agree that I think the attempt here
hasn't worked.

> However, if you don't believe that's feasible, I would be willing to
> champion an effort to try again afresh - either by restarting the
> podling (with Incubator and Maven PMC approval), or choosing a new
> location, and then migrating the current codebase to something more
> suitable with respect to any current users. Hopefully through
> regular communication we could converge over time while being free
> to experiment as needed.
>

It can only help to have more people working on it. I wish you luck
with your endeavors.

> Thanks,
> Brett
>
> On 14/11/2008, at 8:14 AM, Shane Isbell wrote:
>
>> I'd like to let the general NMaven community know that we are
>> dissolving
>> NMaven from the Apache Incubator and will be moving the project to
>> Sonatype
>> Forge (http://sonatype.org) over the next week. I can't speak for all
>> members of the NMaven PPMC but my personal reasons are that after 2
>> years in
>> the incubator, we have failed to gain traction with the community.
>> The
>> community involvement was quite active while NMaven was at
>> sourceforge,
>> drying up very quickly after moving to ASF.
>>
>> Looking back, I think there were a number of reasons for this.
>> First, I
>> don't think the Apache brand name has as much appeal to the .NET
>> crowd, so
>> it was easy for us to get buried. Second, we tied NMaven to a Maven
>> 2.1
>> snapshot to support Visual Studio, and thus were stuck at a point
>> where we
>> couldn't do a release. Finally, I took a divergent path from Maven
>> implementation, in part to solve problems with lack of toolchain
>> support and
>> versionless artifact file names, and this made it difficult for Maven
>> developers to understand and to make contributions. The 0.15
>> release earlier
>> in the year was designed to address these problems. Yet we still
>> didn't gain
>> much traction with the user or developer community, pointing to
>> something
>> more fundamental.
>>
>> Given these problems, I'd like to take NMaven to Sonatype Forge,
>> giving it a
>> fresh start, getting back visibility, community involvement and a
>> steady
>> release schedule. Now in regards to the future plans.
>>
>> A number of .NET developers I talked to said that they while they
>> liked
>> Maven and the concept of the Project Model, they didn't want to
>> have to
>> install Java and Maven on their systems to use it. And finding
>> developers
>> who know Maven, Java and .NET is not the easiest thing, so I'll be
>> putting
>> in some time into Byldan (http://codeplex.com/byldan), a .NET
>> version of
>> Maven. I'm looking to port over the new 3.0 project builder code,
>> so we can
>> start bringing the Byldan project model inline with Maven's pom. We
>> can
>> build the plugins once in .NET and then execute them using either
>> Byldan or
>> NMaven. The unreleased version 0.14 has this .NET plugin support,
>> but that
>> code needs to be rewritten and/or cleaned up. We will need
>> developers with
>> experience in app loading and app domains.
>>
>> Another area I would like to focus on is the Visual Studio support.
>> Eugene
>> has done a lot of work with the m2eclipse plugin, using Lucene
>> indexing of
>> the the POMs for artifact searches, so I'm looking to create similar
>> functionality using Lucene.NET.
>>
>> The final areas of focus are ones that we have been trying to solve
>> from day
>> one: properly handling versionless artifact file names and doing
>> toolchain
>> support, at both the client and server level. These problems are
>> enormously
>> difficult to do against the web based repositories, so I will be
>> looking to
>> integrate NMaven/Byldan with the Nexus Repo Manager Rest APIs, just
>> pegging
>> the technology so we can get things moving more quickly. This
>> should also
>> make things like PDB attached artifacts easier to handle.
>>
>> I'll be posting more transition information over the coming week.
>> Feel free
>> to shoot back with any questions or concerns.
>>
>> Thanks,
>> Shane
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.

-- Paul Graham

Re: Dissolving Apache NMaven From ASF Incubator

2008-11-17T05:29:19Z

I have a number of perspectives on this, and have taken the time
traveling over the last few days to reflect on this decision.

As a mentor, I can recognise the podling in its current form is not
working. Contributions, patches, and questions have gone largely
ignored this year, and development stalled after the migration to a
new trunk. For a long time we have assumed that a kick in that
direction was all that was needed to get it going again, but only
small steps have been taken. Something clearly needs to change.

I don't believe the move you've suggested will make visibility,
community involvement and a steady release schedule any more likely
than it is now - they simply require a conscious decision and group
effort to do so which could equally be achieved here.

My primary role in the project at the moment is as a user, distributor
and occasional developer. There are two reasons your proposal won't
satisfy our needs in that regard:
- we are committed to and required to maintain the code in an
independent environment
- we require integration with Archiva for the search and management
functionality

Do you have some alternative proposition here? I realise these may not
be your personal "itches", but there are no technical reasons they
can't be achieved by other community members that are interested in
doing so while other work continues in the areas you've described.

I personally agree with the overarching technical direction you've
described. In the long term, I see the .NET portions of this project
doing much of the work independently, and this is also consistent with
discussions I've had with others. However, Byldan hadn't seemed much
more than an experiment to date - could you elaborate on where you
think it stands to be able to provide a solution to Maven users today,
or what kind of effort is required to bring it to that point?

I would still urge you to reconsider and give a renewed effort here to
see what we can achieve by openly discussing the issues and roadmap
for everyone that is interested in this project and seeing what comes
of it.

However, if you don't believe that's feasible, I would be willing to
champion an effort to try again afresh - either by restarting the
podling (with Incubator and Maven PMC approval), or choosing a new
location, and then migrating the current codebase to something more
suitable with respect to any current users. Hopefully through regular
communication we could converge over time while being free to
experiment as needed.

Thanks,
Brett

On 14/11/2008, at 8:14 AM, Shane Isbell wrote:

> I'd like to let the general NMaven community know that we are
> dissolving
> NMaven from the Apache Incubator and will be moving the project to
> Sonatype
> Forge (http://sonatype.org) over the next week. I can't speak for all
> members of the NMaven PPMC but my personal reasons are that after 2
> years in
> the incubator, we have failed to gain traction with the community. The
> community involvement was quite active while NMaven was at
> sourceforge,
> drying up very quickly after moving to ASF.
>
> Looking back, I think there were a number of reasons for this.
> First, I
> don't think the Apache brand name has as much appeal to the .NET
> crowd, so
> it was easy for us to get buried. Second, we tied NMaven to a Maven
> 2.1
> snapshot to support Visual Studio, and thus were stuck at a point
> where we
> couldn't do a release. Finally, I took a divergent path from Maven
> implementation, in part to solve problems with lack of toolchain
> support and
> versionless artifact file names, and this made it difficult for Maven
> developers to understand and to make contributions. The 0.15 release
> earlier
> in the year was designed to address these problems. Yet we still
> didn't gain
> much traction with the user or developer community, pointing to
> something
> more fundamental.
>
> Given these problems, I'd like to take NMaven to Sonatype Forge,
> giving it a
> fresh start, getting back visibility, community involvement and a
> steady
> release schedule. Now in regards to the future plans.
>
> A number of .NET developers I talked to said that they while they
> liked
> Maven and the concept of the Project Model, they didn't want to have
> to
> install Java and Maven on their systems to use it. And finding
> developers
> who know Maven, Java and .NET is not the easiest thing, so I'll be
> putting
> in some time into Byldan (http://codeplex.com/byldan), a .NET
> version of
> Maven. I'm looking to port over the new 3.0 project builder code,
> so we can
> start bringing the Byldan project model inline with Maven's pom. We
> can
> build the plugins once in .NET and then execute them using either
> Byldan or
> NMaven. The unreleased version 0.14 has this .NET plugin support,
> but that
> code needs to be rewritten and/or cleaned up. We will need
> developers with
> experience in app loading and app domains.
>
> Another area I would like to focus on is the Visual Studio support.
> Eugene
> has done a lot of work with the m2eclipse plugin, using Lucene
> indexing of
> the the POMs for artifact searches, so I'm looking to create similar
> functionality using Lucene.NET.
>
> The final areas of focus are ones that we have been trying to solve
> from day
> one: properly handling versionless artifact file names and doing
> toolchain
> support, at both the client and server level. These problems are
> enormously
> difficult to do against the web based repositories, so I will be
> looking to
> integrate NMaven/Byldan with the Nexus Repo Manager Rest APIs, just
> pegging
> the technology so we can get things moving more quickly. This should
> also
> make things like PDB attached artifacts easier to handle.
>
> I'll be posting more transition information over the coming week.
> Feel free
> to shoot back with any questions or concerns.
>
> Thanks,
> Shane

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

Dissolving Apache NMaven From ASF Incubator

2008-11-13T13:14:00Z

I'd like to let the general NMaven community know that we are dissolving
NMaven from the Apache Incubator and will be moving the project to Sonatype
Forge (http://sonatype.org) over the next week. I can't speak for all
members of the NMaven PPMC but my personal reasons are that after 2 years in
the incubator, we have failed to gain traction with the community. The
community involvement was quite active while NMaven was at sourceforge,
drying up very quickly after moving to ASF.

Looking back, I think there were a number of reasons for this. First, I
don't think the Apache brand name has as much appeal to the .NET crowd, so
it was easy for us to get buried. Second, we tied NMaven to a Maven 2.1
snapshot to support Visual Studio, and thus were stuck at a point where we
couldn't do a release. Finally, I took a divergent path from Maven
implementation, in part to solve problems with lack of toolchain support and
versionless artifact file names, and this made it difficult for Maven
developers to understand and to make contributions. The 0.15 release earlier
in the year was designed to address these problems. Yet we still didn't gain
much traction with the user or developer community, pointing to something
more fundamental.

Given these problems, I'd like to take NMaven to Sonatype Forge, giving it a
fresh start, getting back visibility, community involvement and a steady
release schedule. Now in regards to the future plans.

A number of .NET developers I talked to said that they while they liked
Maven and the concept of the Project Model, they didn't want to have to
install Java and Maven on their systems to use it. And finding developers
who know Maven, Java and .NET is not the easiest thing, so I'll be putting
in some time into Byldan (http://codeplex.com/byldan), a .NET version of
Maven. I'm looking to port over the new 3.0 project builder code, so we can
start bringing the Byldan project model inline with Maven's pom. We can
build the plugins once in .NET and then execute them using either Byldan or
NMaven. The unreleased version 0.14 has this .NET plugin support, but that
code needs to be rewritten and/or cleaned up. We will need developers with
experience in app loading and app domains.

Another area I would like to focus on is the Visual Studio support. Eugene
has done a lot of work with the m2eclipse plugin, using Lucene indexing of
the the POMs for artifact searches, so I'm looking to create similar
functionality using Lucene.NET.

The final areas of focus are ones that we have been trying to solve from day
one: properly handling versionless artifact file names and doing toolchain
support, at both the client and server level. These problems are enormously
difficult to do against the web based repositories, so I will be looking to
integrate NMaven/Byldan with the Nexus Repo Manager Rest APIs, just pegging
the technology so we can get things moving more quickly. This should also
make things like PDB attached artifacts easier to handle.

I'll be posting more transition information over the coming week. Feel free
to shoot back with any questions or concerns.

Thanks,
Shane

Re: partial classes

2008-11-13T03:09:11Z

Sorry, my fault again, I should have added another source directory
"gtk-gui" created by monodevelop.

partial classes

2008-11-13T03:02:48Z

nmaven cannot deal with partial classes (the ones generated by
monodevelop GUI builder)

I don't know how partial classes must be compiled, but nmaven cannot
compile them. It complains of the missing element in the partial class
(which of course are defined in the another file)

Have you got any suggestions?

Re: help with dependencies please

2008-11-13T02:49:27Z

My fault. I forgot do add
<type>dotnet:gac_msil</type>

help with dependencies please

2008-11-13T02:40:08Z

Hello, I'm building an assembly with maven which depends on
gtk-sharp.dll and System.Runtime.Remoting.dll. I tried to put a
dependency in pom.xml but without success: I don't know which is the
groupId and artifactId of both dll

<dependency>
<groupId>Gtk</groupId>
<artifactId>Gtk</artifactId>
<version>2.12.0.0</version>
<scope>system</scope>
<systemPath>
/usr/lib/mono/gtk-sharp-2.0/gtk-sharp.dll
</systemPath>
</dependency>

<dependency>
<groupId>System.Runtime.Remoting</groupId>
<artifactId>System.Runtime.Remoting</artifactId>
<version>2.0.0.0</version>
<scope>system</scope>
<systemPath>
/usr/lib/mono/2.0/System.Runtime.Remoting.dll
</systemPath>
</dependency>

the output of mvn install is the following:

[...]
The type or namespace name `Http' does not exist in the namespace
`System.Runtime.Remoting.Channels'. Are you missing an assembly
reference?
[...]
The type or namespace name `Gtk' could not be found. Are you missing a
using directive or an assembly reference?
[...]
Command = /bin/sh -c "gmcs
/out:/home/yelo3/EsameIS/SimulationBelt/target/SimulationBelt-1.0.exe
/target:exe /recurse:/home/yelo3/EsameIS/SimulationBelt/target/build-sources/**
/reference:/home/yelo3/.m2/repository/it/unibo/deis/EsameIS/Belt/1.0/Belt-1.0.dll
/reference:/home/yelo3/.m2/repository/it/unibo/deis/EsameIS/NetworkServices/1.0/NetworkServices-1.0.dll
/reference:/home/yelo3/.m2/repository/it/unibo/deis/EsameIS/Container/1.0/Container-1.0.dll
/warnaserror- /reference:System.Drawing
/reference:System.Windows.Forms /reference:System.Web.Services
/doc:/home/yelo3/EsameIS/SimulationBelt/target/comments.xml"

Re: How to make manual artifacts using classifiers

2008-11-11T07:54:07Z

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@...
>
>
>
>

Incubator report for November

2008-11-10T07:33:32Z

Here is what I have so far - any additions/changes wanted?

NMaven develops plugins and integration for Maven to make building and
using .NET languages a first-class citizen in Maven.

Incubating since: 2006-11-17

* Slight increase in mailing list traffic
* Work has progressed on helping to migrate the previous version to
the revised trunk
* Discussion of another release
* Expecting increased contributions in the coming months
* Started to set up a repository on the Maven central repository
for .NET artifacts
* Presented a brief fast feather talk at ApacheCon, but didn't
generate additional interest

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

Re: Versioning artifacts with NMaven

2008-11-09T18:33:06Z

for alpha versions it should be in a 0 series like 0.14 or 0.16.1.2

On Mon, Nov 10, 2008 at 10:32 AM, Leopoldo Agdeppa <lagdeppa@...>wrote:

> should be the one in assembly, and 1.3-alpha1 will be rendered as 1.3 only
>
>
> On Sat, Nov 8, 2008 at 6:21 AM, Wendy Smoak <wsmoak@...> wrote:
>
>> In a different thread, Shane wrote:
>>
>> >You need to use w.x.y.z, but may append it with anything after a hyphen.
>> > For example. 2.0.0.0-SNAPSHOT or 1.3-alpha1 are both okay to use.
>>
>> I found [1] which explains the w.x.y.z versioning, but how does nmaven
>> handle the version in the pom vs. the one in the assembly? If w.x.y.z
>> is a requirement, then how does 1.3-alpha1 work?
>>
>> [1] http://msdn.microsoft.com/en-us/library/51ket42z.aspx
>>
>> Thanks,
>> --
>> Wendy
>>
>
>
>
> --
> Leopoldo L. Agdeppa III
> Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 |
> YM: exst_lagdeppa | www.exist.com | Innovation Delivered
>

Re: Versioning artifacts with NMaven

2008-11-09T18:32:17Z

should be the one in assembly, and 1.3-alpha1 will be rendered as 1.3 only

On Sat, Nov 8, 2008 at 6:21 AM, Wendy Smoak <wsmoak@...> wrote:

> In a different thread, Shane wrote:
>
> >You need to use w.x.y.z, but may append it with anything after a hyphen.
> > For example. 2.0.0.0-SNAPSHOT or 1.3-alpha1 are both okay to use.
>
> I found [1] which explains the w.x.y.z versioning, but how does nmaven
> handle the version in the pom vs. the one in the assembly? If w.x.y.z
> is a requirement, then how does 1.3-alpha1 work?
>
> [1] http://msdn.microsoft.com/en-us/library/51ket42z.aspx
>
> Thanks,
> --
> Wendy
>

Versioning artifacts with NMaven

2008-11-07T14:21:33Z

In a different thread, Shane wrote:

>You need to use w.x.y.z, but may append it with anything after a hyphen.
> For example. 2.0.0.0-SNAPSHOT or 1.3-alpha1 are both okay to use.

I found [1] which explains the w.x.y.z versioning, but how does nmaven
handle the version in the pom vs. the one in the assembly? If w.x.y.z
is a requirement, then how does 1.3-alpha1 work?

[1] http://msdn.microsoft.com/en-us/library/51ket42z.aspx

Thanks,
--
Wendy

Re: How to make manual artifacts using classifiers

2008-11-06T20:03:43Z

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@...

Re: How to make manual artifacts using classifiers

2008-11-06T13:52:45Z

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/
>
>

Re: central repository for NMaven artifacts

2008-11-06T12:51:02Z

This is a reasonable point - though perhaps something we can deal with
at a later point since at the moment there is an overlap, and the
benefit of not needing to configure an additional repository in every
POM is a big one.

- Brett

On 28/10/2008, at 7:25 AM, Mimil wrote:

>
> Hi,
>
> Concerning the repository location I think that having a dedicated
> repository by language (imagine that maven can be used for any
> programming
> language) is a good idea because of the following points:
>
> - it allows to see what is really available for the language you are
> using
> - maybe the maintainers of these repositories will be different ...
>
> Regards,
> Cedric,
>
>
> -----
> May the Moo force be with you,
> Said Mimil
> --
> View this message in context: http://www.nabble.com/central-repository-for-NMaven-artifacts-tp19987877p20206236.html
> Sent from the nmaven-dev mailing list archive at Nabble.com.
>

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

Re: central repository for NMaven artifacts

2008-11-06T12:50:12Z

Good point.

Any other opinions on this? Either way, nunit is going to be an anomaly.

- Brett

On 31/10/2008, at 10:27 PM, Wendy Smoak wrote:

> On Thu, Oct 16, 2008 at 12:06 AM, Brett Porter <brett@...>
> wrote:
>> What I'm led to believe is that CamelCase is the convention for
>> artifacts,
>> and that NUnit might be an exception. For that reason, I have
>> <finalName>nunit.framework</finalName> in the POM rather than break
>> the
>> convention on the artifact ID.
>>
>> Is everyone ok with:
>> * CamelCase as the convention for artifact IDs
>> * using finalName for NUnit rather than changing the artifact ID
>> * selection of (b) below
>
> I think we should respect the name of the artifact as shipped by NUnit
> (and installed into the GAC by the NUnit installer). Otherwise when
> NMaven tries to import a project and searches the repository based on
> the reference in the project file, it isn't going to find a match.
>
> In Java most things are lowercase-with-dashes, but a few artifacts
> like UMLGraph aren't.
>
> --
> Wendy

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

Re: Doc generation plugin

2008-11-06T12:47:13Z

The usual pattern would be to create a plugin for both so that users
can choose. We don't need to bless particular pieces of software.

If there is significant overlap between the plugins, factoring it into
a common component, or having one plugin that can exec both, is a
possibility too.

- Brett

On 31/10/2008, at 5:51 AM, Mimil Mimil wrote:

> Hello,
>
> I wonder if the API documentation generation plugin should not be
> based on
> monodoc (http://www.mono-project.com/Monodoc). In reference to the
> jira
> issue http://jira.codehaus.org/browse/NMAVEN-68.
>
> monodoc is at least available on every OS which is maybe less the
> case for
> Sandcastle Help File Builder (it also sounds to require a lot of other
> tools).
>
> What do you think about this?
>
> PS: I personaly don't know anything on monodoc and neither sandcastle.
>
> Regards,
> Cedric,

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

Re: How to make manual artifacts using classifiers

2008-11-06T10:19:26Z

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/

Re: How to make manual artifacts using classifiers

2008-11-05T19:14:17Z

On Wed, Nov 5, 2008 at 8:36 AM, Mimil Mimil <mimilowns@...> wrote:

>
> 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?

You need to use w.x.y.z, but may append it with anything after a hyphen. For
example. 2.0.0.0-SNAPSHOT or 1.3-alpha1 are both okay to use.

>
>
> 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...

mvn deploy will work fine.

Thanks,
Shane

How to make manual artifacts using classifiers

2008-11-05T08:36:47Z

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,

Re: central repository for NMaven artifacts

2008-10-31T20:27:46Z

On Thu, Oct 16, 2008 at 12:06 AM, Brett Porter <brett@...> wrote:
> What I'm led to believe is that CamelCase is the convention for artifacts,
> and that NUnit might be an exception. For that reason, I have
> <finalName>nunit.framework</finalName> in the POM rather than break the
> convention on the artifact ID.
>
> Is everyone ok with:
> * CamelCase as the convention for artifact IDs
> * using finalName for NUnit rather than changing the artifact ID
> * selection of (b) below

I think we should respect the name of the artifact as shipped by NUnit
(and installed into the GAC by the NUnit installer). Otherwise when
NMaven tries to import a project and searches the repository based on
the reference in the project file, it isn't going to find a match.

In Java most things are lowercase-with-dashes, but a few artifacts
like UMLGraph aren't.

--
Wendy

Doc generation plugin

2008-10-31T03:51:58Z

Hello,

I wonder if the API documentation generation plugin should not be based on
monodoc (http://www.mono-project.com/Monodoc). In reference to the jira
issue http://jira.codehaus.org/browse/NMAVEN-68.

monodoc is at least available on every OS which is maybe less the case for
Sandcastle Help File Builder (it also sounds to require a lot of other
tools).

What do you think about this?

PS: I personaly don't know anything on monodoc and neither sandcastle.

Regards,
Cedric,