Supporting alternative packaging types in 1.2

Coordinator
Mar 16, 2010 at 5:20 AM

Hi,

The current packaging types such as 'library' are not very specific and could end up causing problems clashing with other types in the repository, which is important if we want to host a repository of .NET artifacts.

I'd like to suggest we keep supporting, but deprecate, the existing types in 1.2, and add 'dotnet:*' as synonyms for each (as the past NMaven development did) and encourage their use going forward.

What do others think about including that in 1.2?

Cheers,
Brett

Coordinator
Mar 16, 2010 at 5:26 AM

+1  on that this would be similar to java's jar extensions so we could have exe, dll, etc..

Developer
Mar 23, 2010 at 9:19 AM

Funny. I went to the discussion forums to actually propose exactly this. Seems we are on the same page.

+1

NMaven does dotnet:library, dotnet::* anyway - wasn't that there when NPanday was forked?

I'd suggest to deprecate all extensions in the compiler-plugin. There should be new plugins. One for the core types and one for each lifecycle convention.

Developer
Mar 23, 2010 at 1:12 PM

On my git branch I created a core-types-maven-plugin, where I build the components.xml with the types only.

dotnet-* seems to be more appropriate than dotnet:* because maven uses the : as delimiter for printing dependency information.

To avoid violating DRY massively, I generate the plexus-configuration in a groovy script executed on generate-resources.

What do you think?

Coordinator
Mar 23, 2010 at 6:00 PM

agree on dotnet-* instead of dotnet:*

do you think it should be dotnet-exe or dotnet-winexe, while we are changing it?

Also, we need to check if 'nar' is still used.

Developer
Mar 23, 2010 at 7:14 PM

We have to include the current types further on for correct resolving of remote dependencies (if a artifact has a library-dependency, we have to figure out that it is a dll).

I think dotnet-executable would be good.

We could then only transfer those we really need to dotnet-*...

  library -> [name: 'dotnet-library', ext: 'dll'],
  *new [name: 'dotnet-library-config', ext: 'dll.config'],
  winexe -> [name: 'dotnet-executable', ext: 'exe'],
  exe.config -> [name: 'dotnet-executable-config', ext: 'exe.config'],
  module -> [name: 'dotnet-module', ext: 'netmodule'],
  *new [name: 'dotnet-symbols', ext: 'pdb'],
  *new [name: 'ole-type-library', ext: 'tlb'],
  gac -> [name: 'dotnet-gac-library', ext: 'dll'],
  asp -> [name: 'dotnet-aspx-precompiled', ext: 'dll'],

  netplugin -> [name: 'dotnet-maven-plugin', ext: 'dll'], 
  visual-studio-adding -> [name: 'dotnet-visual-studio-addin', ext: 'dll'],

What about these?
  [name: 'dotnet-gac_generic', ext: 'dll'], 
  [name: 'dotnet-gac_msil', ext: 'dll'], 

  [name: 'dotnet-gac_32', ext: 'dll'],
  [name: 'dotnet-nar', ext: 'nar'], 


   // deprecated, included for convenience
  [name: 'library', ext: 'dll'],
  [name: 'winexe', ext: 'exe'],
  [name: 'exe.config', ext: 'exe.config'],
  [name: 'module', ext: 'netmodule'],
  [name: 'asp', ext: 'dll'],
  [name: 'gac', ext: 'dll'],
  [name: 'gac_generic', ext: 'dll'],
  [name: 'gac_msil', ext: 'dll'],
  [name: 'gac_32', ext: 'dll'],
  [name: 'nar', ext: 'nar'],
  [name: 'netplugin', ext: 'dll'],
  [name: 'visual-studio-addin', ext: 'dll'],

 

Developer
Mar 23, 2010 at 7:20 PM

I can't really find com_reference specified.... I'll need this next week for a VB6 build. NPanday is for .NET and Microsoft, right? So com-library would be OK to add? I always added *.tlb as ole-type-liberary.

Coordinator
Mar 24, 2010 at 12:00 AM

Good list, especially the new additions. Though I'm getting a bit cautious about the length of some of the types (dotnet-gac and dotnet-asp still seem sufficient to me). I'm not actually sure if v-s-addin needs to be a unique type either now.

For the other GAC types - I'm not familiar with how they are used so we'd need to look into it.

For com_reference - I think this might be used in the code to change the way the compiler works but not necessarily declared. That would need improving.

Developer
Mar 24, 2010 at 12:35 PM

Hi again,

ok. Is it asp, or aspx, btw?

Found that there already is a registry of types in dotnet-core, class ArtifactType.

So I refactored a little:

public enum ArtifactType
{

    NULL( "null", "null", "null" ),
   DOTNET_MODULE("dotnet-module", "module", "netmodule"),
DOTNET_LIBRARY("dotnet-library", "library", "dll"),

DOTNET_LIBRARY_CONFIG("dotnet-library-config", "null", "dll.config"),

DOTNET_EXECUTABLE("dotnet-executable", "exe", "exe"),
DOTNET_EXECUTABLE_CONFIG("dotnet-executable-config", "null", "exe.config"),

DOTNET_GAC("dotnet-gac", "null", "dll"),

// zip or dll? DOTNET_ASPX("dotnet-aspx", "library", "dll"), //DOTNET_("dotnet-gac_generic", "library", "dll"), //DOTNET_("dotnet-gac_msil", "library", "dll"), //DOTNET_("dotnet-gac_32", "library", "dll"), //DOTNET_("dotnet-nar", "library", "nar"), //DOTNET_("dotnet-netplugin", "library", "dll"), //DOTNET_("dotnet-visual-studio-addin", "library", "dll"), DOTNET_SYMBOLS("dotnet-symbols", "null", "pdb"),
DOTNET_OLE_TYPE_LIB("ole-type-library", "null", "tlb"),

@Deprecated
MODULE( "module", "module", "netmodule" ),

@Deprecated
LIBRARY( "library", "library", "dll" ),

@Deprecated
EXE( "exe", "exe", "exe" ),

@Deprecated
WINEXE( "winexe", "winexe", "exe" ),

@Deprecated
NAR( "nar", "null", "nar" ),

@Deprecated
EXECONFIG( "exe.config", "null", "exe.config" ),

@Deprecated
NETPLUGIN( "netplugin", "library", "dll" ),

@Deprecated
VISUAL_STUDIO_ADDIN( "visual-studio-addin", "library", "dll" ),

@Deprecated
SHARP_DEVELOP_ADDIN( "sharp-develop-addin", "library", "dll" ),

@Deprecated
ASP ( "asp", "library", "zip" ),

@Deprecated
GAC ( "gac", "null", "dll"),

@Deprecated
GAC_GENERIC ("gac_generic", "null", "dll"),

@Deprecated
GAC_MSIL ("gac_msil", "null", "dll"),

@Deprecated
GAC_32 ( "gac32", "null", "dll")

A new plugin 'custom-lifecycle-maven-plugin' generates a Nexus config with type handlers and empty lifecycles. 'core-types-maven-plugin' is deleted.

 

Developer
Mar 24, 2010 at 3:27 PM

the reincarnation of nar -> dotnet-archive

We had a discussion here internally regarding pdb's, tlb's and configs. Really those are not artifacts. They should be in the assembly - but the .NET concept doesn't allow that.

Currently nar is used for packaging web-projects. From nar-lifecycle-mapping:

 

<package>npanday.plugin:maven-webapp-plugin:package</package>
<deploy>npanday.plugin:maven-webapp-plugin:deploy</deploy>

 

I think allways packaging .NET artifacts into a zip/nar would give us huge benefits!

  1. less types!
  2. less files to deploy and resolve (saves download times and masses of log-outputs)
  3. it's more maven-like
  4. easy and proper usage of classifiers
  5. DLLs in the zip are named as they should: without classifier and version
  6. Package multiple projects into one archive. As groovy-all.jar does. This is sometimes easier than separate artifacts. Who would care about nunit.framework.dll and nunit.core.dll, if you could just add nunit-all.nar?

When you have a dependency on a libarary or dll you just want to get the pdb, config and the xml (intellisense) along! Now you had to create extra types and even new artifacts, or do tricks with maven-helper:attach-artifacts.

And when you then use debug/release plus different .net-versions for classifiers, you have just too many files in your artifacts folder.

Let us compare. log4net is a port of log4j and it is a appache project. Aggree, that this should be easily built and distributed with NPanday, right?

So lets have a look at the artifacts this would have, using separate types per file:

log4net-1.2.10-cli-1.0-release.xml
log4net-1.2.10-cli-1.0-release.dll

log4net-1.2.10-mono-1.0-release.dll
log4net-1.2.10-mono-1.0-release.xml
log4net-1.2.10-mono-1.0-debug.dll
log4net-1.2.10-mono-1.0-debug.mdb
log4net-1.2.10-mono-1.0-debug.xml

log4net-1.2.10-mono-2.0-release.dll
log4net-1.2.10-mono-2.0-release.xml
log4net-1.2.10-mono-2.0-debug.dll
log4net-1.2.10-mono-2.0-debug.mdb
log4net-1.2.10-mono-2.0-debug.xml

log4net-1.2.10-net-1.0-release.dll
log4net-1.2.10-net-1.0-release.xml
log4net-1.2.10-net-1.0-debug.dll
log4net-1.2.10-net-1.0-debug.pdb
log4net-1.2.10-net-1.0-debug.xml

log4net-1.2.10-net-1.1-release.dll
log4net-1.2.10-net-1.1-release.xml
log4net-1.2.10-net-1.1-debug.dll
log4net-1.2.10-net-1.1-debug.pdb
log4net-1.2.10-net-1.1-debug.xml

log4net-1.2.10-net-2.0-release.dll
log4net-1.2.10-net-2.0-release.xml
log4net-1.2.10-net-2.0-debug.dll
log4net-1.2.10-net-2.0-debug.pdb
log4net-1.2.10-net-2.0-debug.xml

log4net-1.2.10-netcf-1.0-release.dll
log4net-1.2.10-netcf-1.0-release.xml
log4net-1.2.10-netcf-1.0-debug.dll
log4net-1.2.10-netcf-1.0-debug.pdb
log4net-1.2.10-netcf-1.0-debug.xml

log4net-1.2.10-sscli-1.0-release.dll
log4net-1.2.10-sscli-1.0-debug.dll
log4net-1.2.10-sscli-1.0-debug.ildb

This could easily be reduced to:

log4net-1.2.10-cli-1.0-release.nar
log4net-1.2.10-cli-1.0-release.nar
log4net-1.2.10-mono-1.0-release.nar
log4net-1.2.10-mono-1.0-debug.nar
log4net-1.2.10-mono-2.0-release.nar
log4net-1.2.10-mono-2.0-debug.nar
log4net-1.2.10-net-1.0-release.nar
log4net-1.2.10-net-1.0-debug.nar
log4net-1.2.10-net-1.1-release.nar
log4net-1.2.10-net-1.1-debug.nar
log4net-1.2.10-net-2.0-release.nar
log4net-1.2.10-net-2.0-debug.nar
log4net-1.2.10-netcf-1.0-release.nar
log4net-1.2.10-netcf-1.0-debug.nar
log4net-1.2.10-sscli-1.0-release.nar
log4net-1.2.10-sscli-1.0-debug.nar

The workflow is very simple. It would be like for jar, with these additions:

  • dependency:resolve downloads the jar and unpacks it into a cache-folder. This also solves the problem with the required naming of dll's.
  • dependency:copy-dependencies unpacks nars in the target folder
  • compile and compile-tests would just add all *.dll and *.exe within the nar to it's class-path
  • package packages it up
  • deploy deploys the jar

I think this should rather be the new NPanday-way, hence dotnet-libary and dotnet-executable and many other types would just not be necessary anymore. libary and winexe would be deprecated but still work until version 2.0.

What do you think?

Developer
Mar 24, 2010 at 3:35 PM

The nar would also need something like a manifest that describes dll's that have to be registered as com-references or gac-installs.

Developer
Mar 25, 2010 at 10:27 AM

Even more input :-)

Maybe *.dll.zip and *.exe.zip would make it easier to grasp.

- Lars

 

Coordinator
Apr 1, 2010 at 1:38 AM
larscorneliussen wrote:

Hi again,

ok. Is it asp, or aspx, btw?

Probably aspx - but either is fine with me. I went for shorter, but I'm not sure asp is really accurate.

Coordinator
Apr 1, 2010 at 1:49 AM

Regarding 'nar' - though I continue to look at it, my preference is really for original files in the repository. That is much more the "Maven way" - these should be handled similarly to -sources and -javadoc in Java. If the DLL can be used without the .xml and .pdb, then it should be available separately. Also consider the implications for signing releases - when Maven adds GPG support you'd want signatures from the original releases, not a new packaging we had to create. Likewise, if you wanted to later add .pdb to a release that previously only had .xml and .dll, if they were separate you could, but if they were bundled you'd need to modify the release artifact which Maven doesn't allow.

I don't mind this as an optional extra for convenience, but I don't think it should be a core part of the NPanday process. As long as Maven/NPanday do the smarts, dealing with large numbers of files (including necessary renames) shouldn't be a hassle.

The workflow you proposed should actually still be suitable - with the resolve step able to retrieve additional data as needed / configured, as well as renaming files for use.

We may end up having a lot of valuable input for Maven 3.1+ about how to come up with a suitable scheme for dealing with classifiers and types and associated artifacts more transparently - I think in the long run that's a better route to go than building internal infrastructure to deal with it (which has bitten the project before!)

 

Coordinator
Apr 1, 2010 at 2:19 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.