"pgier" wrote : I spent some time the last couple weeks trying to reproduce the various module artifacts from the ant build using the maven assembly plugin. I can reproduce the jars but it might be better to use different names than we currently use. The assembly plugin can create jars with the same names locally (what I tried doing at first), but when the deploy plugin deploys stuff to the maven repository it changes the names to fit the maven standard. I believe the reasoning for this has to do with the dependency resolution. | | So for example, instead of jboss-system-client.jar we'll end up with jboss-as-system-${version}-client.jar. Where "client" is a maven classifier that can be used to itdentify this jar as a dependency. | (http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system/5.0.0...) | See build 8 for an example of the client jar. | | So while the names are not the same, I tried to follow a pattern in the naming conventions in order to make it easier to find the matching jars. Will this work? That's fine for the repo, but in the release there should be no version in the jar name. jbossall-client.jar will contain a Class-Path (soon) which has all jar names in it. I don't want to re-jar because we do a component update. (That's the thing we want to get rid of.) "pgier" wrote : I can change jboss-as-system to jboss-system (and follow the pattern for the rest of the artifacts) if it helps. I just chose that convention because I thought it would make it easier to identify app server component vs. mc components, aop components, etc. | Personally I don't care if it's called jboss-as-system or jboss-system. We need to redo the class path entries into our build anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127996#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...