IMO you want a build number, not a version. Two very different things.
Modules are released by hand with a unique version. Products (EARs,
etc) are merely a set of versioned modules with a unique build number.
There's no need to label or release every module since the source was
already labelled
Hi Fabrizio,
Can you please provide unit tests for your last commit in the repository plugin
(BundlePackMojo)?
The code coverage for the plugin went down from 90% to 29% after your commit :)
Most agreed on unit testing and code coverage as discussed in http://mail-archives.apache.org/mod_mbox/m
Carlos,
This is still your prepare release mojo test for encoding. Any idea why
it fails in Continuum (Fedora Core 3), and not Windows?
- Brett
Continuum Build Server wrote:
Online report :
http://ci.codehaus.org/continuum-maven/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/
Hi Lukas,
+1 for aspectJ, jar and junit-report.
+0 for test because I just update some of its dependencies (Xerces & Co -
MAVEN-1753) and I didn't yet test it with maven 1.0.2.
Cheers
Arnaud
On 4/20/06, Lukas Theussl <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Please vote on the following m1 plu
Hi,
I would like to contribute a Maven 1.x plug-in for Agitar (www.agitar,com).
Could some one tell me the procedure to follow? Also I am not sure whether I
should contribute to this site or to the plug-ins site at soureforge.
Thanks
Dan, this sounds like the process we like to use too.
Wayne
On 4/21/06, dan tran <[EMAIL PROTECTED]> wrote:
> Mike , the requirements for SCM are to tag (label) the entire soure tree
> before the build for reproduciblity and QA uses the tag for their issue
> tracking
> purpose. The tag is the ${v
On Sat, 22 Apr 2006, Mike Perham wrote:
> What is the policy for deploying SNAPSHOTs? Several people have been
> asking for the changes plugin and it would be nice to get them at least
> a binary snapshot release so they do not have to checkout the source,
> compile by hand and deploy to their ow
