Feeds:
Posts
Comments

Archive for the ‘NPanday’ Category

For my current work on Azure integration for NPanday I’m investigating what the Azure Tools do with the Service Configuration (*.cscfg) on publish, since the file in Visual Studio it isn’t the same as one which is deployed along with the Cloud Service Package (*.cspkg).

The build & package part for Azure Cloud Services can be found in %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.6\Microsoft.WindowsAzure.targets

Find and copy

First, the build tries to figure out which configuration to build use as input by checking for ServiceConfiguration.$(TargetProfile).ccfg and ServiceConfiguration.ccfg, while $(TargetProfile) is “Cloud” by default.

As a part of the build, after being copied, the configuration file is augmented with more settings.

Add “file generated” comment

That was why I noticed, that the files are different. The comment in the target file makes it look like the file is generated from scratch, but instead it is just a copy which changed here and there. By default, the comment is the only change :)

<AddGeneratedXmlComment
  GeneratedFile="@(TargetServiceConfiguration)"
  SourceFile="@(SourceServiceConfiguration)" />

Cloud Tools version

If IntelliTrace or profiling is enabled, this change lets Azure know which versions of the tools are in use.

<AddSettingToServiceConfiguration
   ServiceConfigurationFile="@(TargetServiceConfiguration)"
   Setting ="$(CloudToolsVersionSettingName)"
   Value="$(CloudToolsVersion)"
   Roles="@(DiagnosticAgentRoles)"
   Condition="'$(EnableProfiling)'=='true' or '$(EnableIntelliTrace)'=='true'" />

Intelli Trace

If IntelliTrace is enabled, it will add a connection string to the configuration:

<AddIntelliTraceToServiceConfiguration
  ServiceConfigurationFile="@(TargetServiceConfiguration)"
  IntelliTraceConnectionString="$(IntelliTraceConnectionString)"
  Roles="@(DiagnosticAgentRoles)"/>

Profiling

If profiling is enabled, it will add an connection string, where to store profiling data.

<AddSettingToServiceConfiguration
  ServiceConfigurationFile="@(TargetServiceConfiguration)"
  Setting ="Profiling.ProfilingConnectionString"
  Value="$(ProfilingConnectionString)"
  Roles="@(DiagnosticAgentRoles)" />

Remote Desktop

If remote desktop is set to be enabled, the build configures this switch in the cloud service configuration, too:

<ConfigureRemoteDesktop
      ServiceConfigurationFile="@(TargetServiceConfiguration)"
      ServiceDefinitionFile="@(TargetServiceDefinition)"
      Roles="@(RoleReferences)" 
      RemoteDesktopIsEnabled="$(EnableRemoteDesktop)"
      />  

Web Deploy

If WebDeploy is enabled for any of your web roles, it will add an endpoint to the definition and set the instance count to zero for all web roles in the service configuration.

<EnableWebDeploy
  ServiceConfigurationFile="@(TargetServiceConfiguration)"
  ServiceDefinitionFile="@(TargetServiceDefinition)"
  RolesAndPorts="$(WebDeployPorts)" />

Connection String Override

If ‘ShouldUpdateDiagnosticsConnectionStringOnPublish’ is set to true, the diagnostics connection string is overridden for all roles in order to prevent the default setting “UseDevelopmentStorage=true” to be published to the cloud.

This is one of the typical “Microsoft demo-ready” features. Most certainly you’ll have multiple role-spanning connection strings or settings that you’d like to change on publish, but this is the only one needed to get demos to run, right?

<SetServiceConfigurationSetting 
  Roles="$(DiagnosticsConnectionStringRoles)"
  ServiceConfigurationFile="@(TargetServiceConfiguration)"
  Setting="$(DiagnosticsConnectionStringName)"
  Value="$(DiagnosticsConnectionStringValue)" />

Corresponding parameters in NPanday

The most complex part in the build is the setup for profiling and IntelliTrace; currently we have no plans on supporting these in NPanday. We will rather just deploy from Visual Studio, in case we need profiling or IntelliTrace.

I still have to look at how RDP and MSDeploy can be added to the configured service configuration; for a first release of NPanday that may have to be done manually.

Read Full Post »

I’ll make it short: it’s a mess. You can’t use plexus container 1.5-tooling (with java annotations), if you have to load your components in a plexus 1.0.x-container – which is the case, if your components are utilized in a Maven 2.2.x Mojo. This is simply because plexus container 1.5.x uses “default” as a default role-hint, while NULL is the default in plexus 1.0.x.

But you can use the old tooling, plexus-maven-plugin. But by default it fails if it sees any annotation in your source code, because it uses a version of qdox that doesn’t know annotations yet.

Also, when generating the component descriptor it doesn’t merge with the manually defined one in src/resources (the new one does).

And since, by default, the merge-descriptors goal runs before descriptor (generate) goal, you have to do some back flips to get that running too.

Well here is a configuration that works. At least in my project. Today.

<plugin>
  <groupId>org.codehaus.plexus</groupId>
  <artifactId>plexus-maven-plugin</artifactId>
  <version>1.3.8</version>
  <dependencies>
    <dependency>
      <groupId>com.thoughtworks.qdox</groupId>
      <artifactId>qdox</artifactId>
      <version>1.12</version>
    </dependency>
  </dependencies>
  <executions>
    <execution>
      <phase>process-classes</phase>
      <goals>
        <goal>descriptor</goal>
        <goal>merge-descriptors</goal>
      </goals>
      <configuration>
        <!-- descriptor config -->
        <outputDirectory>${project.build.directory}</outputDirectory>
        <fileName>plexus/auto-components.xml</fileName>

        <!-- merge config -->
        <descriptors>
          <descriptor>${project.build.directory}/plexus/auto-components.xml</descriptor>
          <descriptor>${basedir}/src/main/resources/META-INF/plexus/components.xml</descriptor>
        </descriptors>
      </configuration>
    </execution>
  </executions>
</plugin>

Note: If you only want to use automatic descriptors, remove all <configuration>…</configuration> contents. The defaults will work then.

You can define that in build/pluginManagement/plugins in your parent pom. Then in your project pom, you just put these four lines in build/plugins:

<plugin>
  <groupId>org.codehaus.plexus</groupId>
  <artifactId>plexus-maven-plugin</artifactId>
</plugin>

Read Full Post »

UPDATE: 1.3-incubating was removed from our main npanday site again! We forgot to ask the Incubator PMC for a vote, so we had to withdraw the official release.

The direct links provided in this post still work though.

Stay tuned for 1.3.1-incubating to be released soon! This will then be moved to group id ‘org.apache.npanday’ and deployed into Maven Central.

We are pleased to announce our first release of NPanday under Apache Incubator! NPanday moved from Codeplex to Apache Incubator last year.

Don’t mind the “incubator” in the version. NPanday is stable, allthough we hope to move from incubator into a full Apache project as soon as possible.

What is NPanday?

NPanday brings Maven to .NET (and Mono). It offers a set of plugins to build and test projects, and it defines all the necessary packaging types for deploying and resolving .NET artifacts.

Apache Maven comes with a great infrastructure for dependency management, artifact transport, artifact repositories, release flows with scm-integration, and much more. If you don’t know Maven, go read here. Maven is great!

There is also a Visual Studio 2005/2008/2010 Integration for English Visual Studio installations.

Why NPanday, now there is NuGet

Wrong question. Competition is great. Sad though, that at least some of the originators for NuGet didn’t even know about Maven and NPanday.

Maven is an ecosystem grown over almost 10 years. It has much more to offer than auto-download of dependencies. Still I think we need to integrate the dependency-resolving and deployment part with nuget and nuget-gallery (See future plans).

What is new in this release?

NPanday now supports .NET 4.0 and Visual Studio 2010. There has also been major internal improvements. The PAB and UAC directories where removed. Now NPanday uses a clean maven local repository. This also removed the necessity for custom additions to the install and deploy phases – which where duplications of the corresponding maven plugins.

Read the full Release Notes for NPanday 1.3-incubating

What are the future plans?

On short notice we will release 1.3.1-incubating, which already has 9 resolved issues and only one left to be fixed.

At the same time we are working on version 2.0, which is a huge internal change. NPanday uses a internal RDF database where it keeps additional information for artifacts and dependencies. This is obsolete, but lots of work to remove.

We also want to lead NPanday to more .NET-like conventions for directory structures i.e., while still maintaining the Maven-influenced layout.  Of course we also try to improve stability, ease of use and documentation.

My agenda for NPanday:

We are 4-5 active committers from which 2 work full-time on NPanday as of today. We would really like to get more committers involved. Find out on how to develop NPanday in the NPanday Developer’s Guide.

Where do I get it?

You’ll find everything you need here: NPanday – NPanday Overview

Downloads: NPanday – Download

Current Docs: NPanday – Documentation

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 432 other followers