Package functionality into fewer projects/plugins

Jun 23, 2010 at 9:19 AM


just interested what you guys think about this....

Maven has tons of plugins in separate projects - but there is a simple reason for that. They release independently - we don't!

So here is my suggestion:

Lets package all plugins into one called npanday-maven-plugin and just have many goals. This would reduce complexity alot.

The same with the components. If we really need them, they are core to npanday - hence npanday-core. For trying out things we could consider starting a separate npanday-contrib/npanday-contrib-maven-plugin that has less restrictions - and then move things into the core when they are stable. The contrib would then be released separately.

Any drawbacks here? What do you think?

Jun 23, 2010 at 3:45 PM

I think it's the right direction, but possibly too far to the other extreme :) I think around 3-5 modules for each of the core, plugins and addin sounds about right.

There are a lot of redundant plugins - removing them, and more accurately naming the "compile" plugin would definitely be a good idea. I do think we could get away with a single plugin for mojos related to the .NET framework tools + standard types, then have separate plugins for other tools.

Likewise, I think we can consolidate libraries, though some separation of concerns is good if you want to reuse portions across plugins or other tools. Broadly, I think we need modules for handling common .NET types, for constructing a toolchain and executing the tools, and for doing .NET artifact handling (more closely built on Maven's libraries than now).

The guideline I use for splitting things up is around the dependencies - if you start dragging in dependencies unnecessary for some operations, the module should be split. If you have a lot of interdependencies that are generally all the same (like now) then the modules should be merged.

I generally like to refactor code like this bidirectionally:

  • figure out our ideal structure and start fresh, implementing small pieces of functionality that can be integrated into the existing code and grow naturally
  • take out pieces of old code that can be replaced (eg, we could start with all the RDF, UAC and PAB references, pointing to libraries of Maven utilities and local repository path utilities)
  • remove the old code over time

Also, I think we are at a stage where the Visual Studio addin (and several dotnet/assemblies modules) should be a separate trunk and release point to the Maven plugins.

Either way, if we take the approach above we can probably start with a core and start to build it out, then see when new modules are needed.