<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
It's not only surefire - also WAR plugin, Cargo, and other...<BR>
<BR>
Ondra<BR>
<BR>
<BR>
Aleksandar Kostadinov p&#237;&#353;e v P&#225; 09. 04. 2010 v 21:24 +0300:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Doesn't surefire plug-in overcome the problem using a manifest file?

Ond&#345;ej &#381;i&#382;ka wrote, On 04/09/2010 09:08 PM (EEST):
&gt; Few weeks ago, we (QA dept) discussed your second option - to distribute
&gt; the deps in a form of maven repository.
&gt; Taking our mavenization trend into account, that would be beneficial
&gt; because Maven-based testsuites could work with the *ARs from the
&gt; distribution without needing to do mvn install:install-file for each
&gt; artifact needed in the process.
&gt; 
&gt; The problem could be the limited length of classpath on some systems.
&gt; 
&gt; Ondra
&gt; 
&gt; 
&gt; 
&gt; Bill Burke p&#237;&#353;e v &#268;t 01. 04. 2010 v 17:19 -0400:
&gt;&gt; instead of the way our JBoss AS distribution is structure now, why not 
&gt;&gt; introduce the idea of maven-based booting and deployment?
&gt;&gt;
&gt;&gt; Core components (specifically deployers, sars, really anything in the 
&gt;&gt; JBoss domain) of a profile (default, minimal, all, etc.) would only 
&gt;&gt; include bean.xml and other configuration files.  Within beans.xml or a 
&gt;&gt; different file, each deployment unit would specify its dependencies, 
&gt;&gt; either through &lt;dependency&gt; elements, or a list of maven artifacts, i.e.
&gt;&gt;
&gt;&gt; org.jboss.resteasy:resteasy-jaxrs:2.0
&gt;&gt;
&gt;&gt; That way our distribution can be either very very tiny, just a zip of 
&gt;&gt; text files that point to our maven repository.  Or, very optimized, we 
&gt;&gt; ship a maven repository with the distribution that shared between the 
&gt;&gt; different profiles.
&gt;&gt;
&gt;&gt; This could get very interesting over time.  Deployment units could 
&gt;&gt; delegate to the base AS for versioning, much like maven modules delegate 
&gt;&gt; to a parent pom for dependency versions.  We could automatically create 
&gt;&gt; scoped deployments or issue warnings if base AS and the deployment unit 
&gt;&gt; require different library versions, etc.
&gt;&gt;
&gt;&gt; Just a thought...
&gt;&gt;
&gt;&gt; Bill
&gt;&gt;
&gt;&gt;
&gt; 
&gt; ------------------------------------------------------------------------
&gt; 
&gt; _______________________________________________
&gt; jboss-development mailing list
&gt; <A HREF="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</A>
&gt; <A HREF="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</A>
_______________________________________________
jboss-development mailing list
<A HREF="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</A>
<A HREF="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>