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@apache.org http://blogs.exist.com/bporter/
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@apache.org http://blogs.exist.com/bporter/
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
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@yahoo.com
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.
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@gmail.com>
> 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@gmail.com>
>> 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>
>>>> <!-- the last version number will be used for nmaven artifact
>>>> packaging -->
>>>> <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@users.sourceforge.net</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>
>>>> <!-- dotnet compiler plugin is needed to be aware of
>>>> dot:library packaging -->
>>>> <plugin>
>>>> <groupId>org.apache.maven.dotnet.plugins</groupId>
>>>> <artifactId>maven-dotnet-compiler-plugin</
>>>> artifactId>
>>>> <!--version>0.16-incubating-SNAPSHOT</version-->
>>>> <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@yahoo.com
>>> >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@apache.org>
>>>>> 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>
>>>>>>>> <!-- To define the plugin version in your parent POM
-->
>>>>>>>> <pluginManagement>
>>>>>>>> <plugins>
>>>>>>>> <plugin>
>>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>>>> <version>2.1</version>
>>>>>>>> </plugin>
>>>>>>>> </plugins>
>>>>>>>> </pluginManagement>
>>>>>>>> <!-- To use the plugin goals in your POM or parent
POM
>>>>>>>> -->
>>>>>>>> <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@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>>
>>>> Sincerely,
>>>> James Carpenter
>>>> cell: 832-677-7247
>>>> email: jcarpenter621@yahoo.com
>>>>
>>>>
>>>>
>>>>
>>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
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@gmail.com> 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@gmail.com> 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>
>>> <!-- the last version number will be used for nmaven artifact
>>> packaging -->
>>> <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@users.sourceforge.net</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>
>>> <!-- dotnet compiler plugin is needed to be aware of
>>> dot:library packaging -->
>>> <plugin>
>>> <groupId>org.apache.maven.dotnet.plugins</groupId>
>>> <artifactId>maven-dotnet-compiler-plugin</artifactId>
>>> <!--version>0.16-incubating-SNAPSHOT</version-->
>>> <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@yahoo.com>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@apache.org> 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>
>>>>>>> <!-- To define the plugin version in your parent POM -->
>>>>>>> <pluginManagement>
>>>>>>> <plugins>
>>>>>>> <plugin>
>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>>> <version>2.1</version>
>>>>>>> </plugin>
>>>>>>> </plugins>
>>>>>>> </pluginManagement>
>>>>>>> <!-- To use the plugin goals in your POM or parent
POM -->
>>>>>>> <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@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>>
>>> Sincerely,
>>> James Carpenter
>>> cell: 832-677-7247
>>> email: jcarpenter621@yahoo.com
>>>
>>>
>>>
>>>
>>
>
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@gmail.com> 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>
>> <!-- the last version number will be used for nmaven artifact
>> packaging -->
>> <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@users.sourceforge.net</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>
>> <!-- dotnet compiler plugin is needed to be aware of
>> dot:library packaging -->
>> <plugin>
>> <groupId>org.apache.maven.dotnet.plugins</groupId>
>> <artifactId>maven-dotnet-compiler-plugin</artifactId>
>> <!--version>0.16-incubating-SNAPSHOT</version-->
>> <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@yahoo.com>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@apache.org> 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>
>>>>>> <!-- To define the plugin version in your parent POM -->
>>>>>> <pluginManagement>
>>>>>> <plugins>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>>> <version>2.1</version>
>>>>>> </plugin>
>>>>>> </plugins>
>>>>>> </pluginManagement>
>>>>>> <!-- To use the plugin goals in your POM or parent POM
-->
>>>>>> <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@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
>> Sincerely,
>> James Carpenter
>> cell: 832-677-7247
>> email: jcarpenter621@yahoo.com
>>
>>
>>
>>
>
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.
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
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@apache.org http://blogs.exist.com/bporter/
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?
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
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@apache.org > 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
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@apache.org http://blogs.exist.com/bporter/
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
Sorry, my fault again, I should have added another source directory "gtk-gui" created by monodevelop.
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?
My fault. I forgot do add <type>dotnet:gac_msil</type>
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"
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>
> <!-- the last version number will be used for nmaven artifact packaging
> -->
> <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@users.sourceforge.net</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>
> <!-- dotnet compiler plugin is needed to be aware of
> dot:library packaging -->
> <plugin>
> <groupId>org.apache.maven.dotnet.plugins</groupId>
> <artifactId>maven-dotnet-compiler-plugin</artifactId>
> <!--version>0.16-incubating-SNAPSHOT</version-->
> <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@yahoo.com>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@apache.org> 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>
>>>>> <!-- To define the plugin version in your parent POM -->
>>>>> <pluginManagement>
>>>>> <plugins>
>>>>> <plugin>
>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>> <artifactId>maven-repository-plugin</artifactId>
>>>>> <version>2.1</version>
>>>>> </plugin>
>>>>> </plugins>
>>>>> </pluginManagement>
>>>>> <!-- To use the plugin goals in your POM or parent POM -->
>>>>> <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@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>>
> Sincerely,
> James Carpenter
> cell: 832-677-7247
> email: jcarpenter621@yahoo.com
>
>
>
>
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@apache.org http://blogs.exist.com/bporter/
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@exist.com>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@gmail.com> 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 > -- Leopoldo L. Agdeppa III Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 | YM: exst_lagdeppa | www.exist.com | Innovation Delivered
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@gmail.com> 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
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
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@apache.org> 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>
>>>> <!-- To define the plugin version in your parent POM -->
>>>> <pluginManagement>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-repository-plugin</artifactId>
>>>> <version>2.1</version>
>>>> </plugin>
>>>> </plugins>
>>>> </pluginManagement>
>>>> <!-- To use the plugin goals in your POM or parent POM -->
>>>> <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@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
Sincerely,
James Carpenter
cell: 832-677-7247
email: jcarpenter621@yahoo.com
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@apache.org> 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>
>>> <!-- To define the plugin version in your parent POM -->
>>> <pluginManagement>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-repository-plugin</artifactId>
>>> <version>2.1</version>
>>> </plugin>
>>> </plugins>
>>> </pluginManagement>
>>> <!-- To use the plugin goals in your POM or parent POM -->
>>> <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@apache.org
> http://blogs.exist.com/bporter/
>
>
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@apache.org http://blogs.exist.com/bporter/
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@apache.org> > 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@apache.org http://blogs.exist.com/bporter/
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@apache.org http://blogs.exist.com/bporter/
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>
>> <!-- To define the plugin version in your parent POM -->
>> <pluginManagement>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-repository-plugin</artifactId>
>> <version>2.1</version>
>> </plugin>
>> </plugins>
>> </pluginManagement>
>> <!-- To use the plugin goals in your POM or parent POM -->
>> <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@apache.org
http://blogs.exist.com/bporter/
On Wed, Nov 5, 2008 at 8:36 AM, Mimil Mimil <mimilowns@gmail.com> 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
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>
> <!-- To define the plugin version in your parent POM -->
> <pluginManagement>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-repository-plugin</artifactId>
> <version>2.1</version>
> </plugin>
> </plugins>
> </pluginManagement>
> <!-- To use the plugin goals in your POM or parent POM -->
> <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,
On Thu, Oct 16, 2008 at 12:06 AM, Brett Porter <brett@apache.org> 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
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,
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.
I'll be there On Tue, Oct 21, 2008 at 5:43 PM, Brett Porter <brett@apache.org> wrote: > Hi, > > I've given a "fast feather" talk at two previous ApacheCon's, and so I > applied for the same again this year. These are just 15 minute talks to try > and gather interest in projects. It got scheduled for Wed 5pm - I've asked > for it to be moved earlier, but no word yet. > > Here is the short description: > >> "All About NMaven: .NET support for Apache Maven" >> >> * What it is >> * How it works >> * .NET challenges >> * Latest News - What's next >> * Where Help is Wanted > > > Any other thoughts? Who here will be at the conference? > > Cheers, > Brett > > -- > Brett Porter > brett@apache.org > http://blogs.exist.com/bporter/ > >
Hi, I've given a "fast feather" talk at two previous ApacheCon's, and so I applied for the same again this year. These are just 15 minute talks to try and gather interest in projects. It got scheduled for Wed 5pm - I've asked for it to be moved earlier, but no word yet. Here is the short description: > "All About NMaven: .NET support for Apache Maven" > > * What it is > * How it works > * .NET challenges > * Latest News - What's next > * Where Help is Wanted Any other thoughts? Who here will be at the conference? Cheers, Brett -- Brett Porter brett@apache.org http://blogs.exist.com/bporter/
The pdbcopy command (http://msdn.microsoft.com/en-us/library/cc501198.aspx ) can apparently be used to strip a private PDB down to a public one. If both were needed you could always have csc generate a full version, and then have a simple pdbcopy plugin produce the public version. Of course, you wouldn't even really need a pdbcopy plugin as the exec plugin could do the trick. It simply might be a tad cleaner to have a pdbcopy plugin. I expect most readers already knew this, I simply failed to mention it in the earlier post. On Oct 19, 2008, at 9:00 AM, Brett Porter wrote: > > On 19/10/2008, at 2:38 PM, James Carpenter wrote: > >> I think what really needs to happen is proper support for multiple >> compilation settings (Think release and debug builds.). I believe >> there is already a JIRA issue for this. I haven't really thought >> this out, but I think the compiler plugin should be configurable to >> create multiple compilation artifacts with different option values >> and an associated classifier for each. Secondary artifacts like >> PDB files would of course just be attached artifacts with an >> appropriate classifier. >> >> It is worth nothing, that PDB files can apparently be configured to >> have more or less information. So called "private" PDB files have >> a lot more details than "public" PDB files. Public PDB files >> contain a subset of the information in a private PDB. The >> information in a private PDB is apparently sufficiently detailed to >> make reverse engineering/decompiling code much easier. When a >> company releases a closed source library they will often release >> public PDB files along with the library, but will keep private PDB >> files for internal use. To further complicate things, I believe I >> read one can configure private PDB files to have less information >> than a typical PDB file but more than a public PDB file. Each of >> these would likely need to correlate with their own classifier. >> >> None of the above is really all that tricky. > > Yep, it sounds about right to me. > >> The really tricky part will be how to deal with dependencies when >> compiling, running unit tests, running the assembly plugin, etc. >> It seems dependencies should have an implicit classifier based on >> context. When a release assembly/dll is being built, maven should >> probably use release versions of the dependencies (implicit release >> classifier). When a debug assembly is being built, maven should >> probably use debug versions of the project's dependencies. This is >> to say, the implicit classifier of the dependencies should >> correspond to the classifier associated with the compiler plugin >> configuration being built. By using the appropriate command line >> options it should be possible to concurrently build as many of >> these different assembly types as desired. (Would this just be >> different compiler plugin execution configurations?) > > Yes, I think it would be dangerous for nmaven to start to inventing > solutions to things that belong in maven proper - having been down > that road before and seen the problems it leads to. > > Generally, Maven just builds one thing at a time (so there is a > normal build, then a release profile, and maybe some other profile > for other scenarios). In this case, it seems you might default to > everything off, but then some may enable a full debug PDB in the > normal builds, and in release turn that off and publish a public PDB > instead. > > If for any reason this requires multiple compilations you could add > extra executions, but that sounds odd - you should be able to get > the right set of options for your scenario and then package as > appropriate, and configure differently in different profiles for > different scenarios. > > I believe this works out better for unit tests as well. Assembly > plugin generally takes what you tell it so should work in most > situations. > > What you might want is to start flipping classifiers - debug info > builds add debug info for dependencies, and so on. This is a missing > capability in Maven right now (the corresponding Java use case is > the jdk14/15 builds that have jdk14/15 dependenceis). It's a > limitation in the classifier in that it does actually affect the > metadata, though at present it is considered not to. > >> I think nmaven is already using its own dependency resolver, so >> everything should be quite tractable, but it may be a bit tricky to >> sort out. If I was to attack it I would probably just have to >> evolve the code until it smelled right. I don't think I would be >> able to see all the way to the end solution when I started. > > In trunk, nmaven uses the standard dependency resolver. > >> >> >> When building Java code maven doesn't really have to deal with any >> of this sticky mess. It might be instructive to see how other non- >> Java (C++?) related plugins are handling this. > > There's a few different ways, but you're right - some of the > problems are similar. > > Thanks! > > Cheers, > Brett > > -- > Brett Porter > brett@apache.org > http://blogs.exist.com/bporter/ > Sincerely, James Carpenter cell: 832-677-7247 email: jcarpenter621@yahoo.com
On 19/10/2008, at 2:38 PM, James Carpenter wrote: > I think what really needs to happen is proper support for multiple > compilation settings (Think release and debug builds.). I believe > there is already a JIRA issue for this. I haven't really thought > this out, but I think the compiler plugin should be configurable to > create multiple compilation artifacts with different option values > and an associated classifier for each. Secondary artifacts like > PDB files would of course just be attached artifacts with an > appropriate classifier. > > It is worth nothing, that PDB files can apparently be configured to > have more or less information. So called "private" PDB files have a > lot more details than "public" PDB files. Public PDB files contain > a subset of the information in a private PDB. The information in a > private PDB is apparently sufficiently detailed to make reverse > engineering/decompiling code much easier. When a company releases a > closed source library they will often release public PDB files along > with the library, but will keep private PDB files for internal use. > To further complicate things, I believe I read one can configure > private PDB files to have less information than a typical PDB file > but more than a public PDB file. Each of these would likely need to > correlate with their own classifier. > > None of the above is really all that tricky. Yep, it sounds about right to me. > The really tricky part will be how to deal with dependencies when > compiling, running unit tests, running the assembly plugin, etc. It > seems dependencies should have an implicit classifier based on > context. When a release assembly/dll is being built, maven should > probably use release versions of the dependencies (implicit release > classifier). When a debug assembly is being built, maven should > probably use debug versions of the project's dependencies. This is > to say, the implicit classifier of the dependencies should > correspond to the classifier associated with the compiler plugin > configuration being built. By using the appropriate command line > options it should be possible to concurrently build as many of these > different assembly types as desired. (Would this just be different > compiler plugin execution configurations?) Yes, I think it would be dangerous for nmaven to start to inventing solutions to things that belong in maven proper - having been down that road before and seen the problems it leads to. Generally, Maven just builds one thing at a time (so there is a normal build, then a release profile, and maybe some other profile for other scenarios). In this case, it seems you might default to everything off, but then some may enable a full debug PDB in the normal builds, and in release turn that off and publish a public PDB instead. If for any reason this requires multiple compilations you could add extra executions, but that sounds odd - you should be able to get the right set of options for your scenario and then package as appropriate, and configure differently in different profiles for different scenarios. I believe this works out better for unit tests as well. Assembly plugin generally takes what you tell it so should work in most situations. What you might want is to start flipping classifiers - debug info builds add debug info for dependencies, and so on. This is a missing capability in Maven right now (the corresponding Java use case is the jdk14/15 builds that have jdk14/15 dependenceis). It's a limitation in the classifier in that it does actually affect the metadata, though at present it is considered not to. > I think nmaven is already using its own dependency resolver, so > everything should be quite tractable, but it may be a bit tricky to > sort out. If I was to attack it I would probably just have to > evolve the code until it smelled right. I don't think I would be > able to see all the way to the end solution when I started. In trunk, nmaven uses the standard dependency resolver. > > > When building Java code maven doesn't really have to deal with any > of this sticky mess. It might be instructive to see how other non- > Java (C++?) related plugins are handling this. There's a few different ways, but you're right - some of the problems are similar. Thanks! Cheers, Brett -- Brett Porter brett@apache.org http://blogs.exist.com/bporter/