Re: How to read POM dependencies from file using Maven Resolver
Ok I’ve found a way but it looks complex… Please let me know if there’s a
simpler way.
So I’ve copied the DefaultModelResolver.java class from maven sources (since
it’s package private I couldn’t reuse it!) into my own sources, and then used
what I mentioned below:
private void getArtifactDependenciesFromPOMFile(List
remoteRepositories,
RepositorySystem repoSystem, RepositorySystemSession session) throws
Exception
{
ModelResolver resolver = new DefaultModelResolver(session, null, null,
this.artifactResolver,
this.versionRangeResolver, this.remoteRepositoryManager,
remoteRepositories);
DefaultModelBuildingRequest modelBuildingRequest = new
DefaultModelBuildingRequest()
.setPomFile(new File("./pom.xml"))
.setModelResolver(resolver);
ModelBuilder modelBuilder = new DefaultModelBuilderFactory().newInstance();
ModelBuildingResult modelBuildingResult =
modelBuilder.build(modelBuildingRequest);
Model model = modelBuildingResult.getEffectiveModel();
…
}
Is that the only way?
Thanks
-Vincent
> On 20 Jul 2018, at 16:56, Vincent Massol wrote:
>
> Hi guys,
>
> I’ve been trying to find how to programmatically resolve dependencies from a
> pom.xml file by using the Maven Resolver API
> (https://github.com/apache/maven-resolver).
>
> So far I’ve succeeded in resolving dependencies from an Artifact but I
> haven’t found how to do by reading from a pom.xml file.
>
> The closest I have founds is the following but it’s not working & it’s not
> using the Resolver API (and thus the passed parameters):
>
> private void getArtifactDependenciesFromPOMFile(List
> remoteRepositories, RepositorySystem repoSystem,
>RepositorySystemSession session) throws Exception
> {
>DefaultModelBuildingRequest modelBuildingRequest = new
> DefaultModelBuildingRequest()
>.setPomFile(new File("./pom.xml”));
>ModelBuilder modelBuilder = new DefaultModelBuilderFactory().newInstance();
>ModelBuildingResult modelBuildingResult =
> modelBuilder.build(modelBuildingRequest);
>Model model = modelBuildingResult.getEffectiveModel();
> }
>
> It’s failing with:
>
> java.lang.NullPointerException: request.modelResolver cannot be null (parent
> POM org.xwiki.platform:xwiki-platform-test:10.6-SNAPSHOT and POM
> org.xwiki.platform:xwiki-platform-test-war:[unknown-version]
> (/Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-test/xwiki-platform-test-war/./pom.xml))
>
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:994)
>
> I assume that’s because it needs some MavenResolver at:
>
>DefaultModelBuildingRequest modelBuildingRequest = new
> DefaultModelBuildingRequest()
>.setPomFile(new File("./pom.xml”))
>.setResolver(“… what to put here?…”)
>
> Is there another approach?
>
> Thanks
> -Vincent
>
> PS: I’ve tried using ShrinkWrap but it’s not working for me, see
> https://massol.myxwiki.org/xwiki/bin/view/Blog/ResolveMavenArtifactsShrinkWrap
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
How to read POM dependencies from file using Maven Resolver
Hi guys,
I’ve been trying to find how to programmatically resolve dependencies from a
pom.xml file by using the Maven Resolver API
(https://github.com/apache/maven-resolver).
So far I’ve succeeded in resolving dependencies from an Artifact but I haven’t
found how to do by reading from a pom.xml file.
The closest I have founds is the following but it’s not working & it’s not
using the Resolver API (and thus the passed parameters):
private void getArtifactDependenciesFromPOMFile(List
remoteRepositories, RepositorySystem repoSystem,
RepositorySystemSession session) throws Exception
{
DefaultModelBuildingRequest modelBuildingRequest = new
DefaultModelBuildingRequest()
.setPomFile(new File("./pom.xml”));
ModelBuilder modelBuilder = new DefaultModelBuilderFactory().newInstance();
ModelBuildingResult modelBuildingResult =
modelBuilder.build(modelBuildingRequest);
Model model = modelBuildingResult.getEffectiveModel();
}
It’s failing with:
java.lang.NullPointerException: request.modelResolver cannot be null (parent
POM org.xwiki.platform:xwiki-platform-test:10.6-SNAPSHOT and POM
org.xwiki.platform:xwiki-platform-test-war:[unknown-version]
(/Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-test/xwiki-platform-test-war/./pom.xml))
at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:994)
I assume that’s because it needs some MavenResolver at:
DefaultModelBuildingRequest modelBuildingRequest = new
DefaultModelBuildingRequest()
.setPomFile(new File("./pom.xml”))
.setResolver(“… what to put here?…”)
Is there another approach?
Thanks
-Vincent
PS: I’ve tried using ShrinkWrap but it’s not working for me, see
https://massol.myxwiki.org/xwiki/bin/view/Blog/ResolveMavenArtifactsShrinkWrap
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Release process
On Mar 4, 2008, at 6:13 AM, Wendy Smoak wrote: On Mon, Mar 3, 2008 at 7:29 PM, Arash Bizhan zadeh [EMAIL PROTECTED] wrote: There is 6 Tomcat 5.5 sandboxes, all of them running on RHE 6. There is a load balancer in front of them and we need to release every app on all of them. I am looking for the best practices to manage the releases. This is more deployment (and configuration management) than release. Take a look at Lokahi, currently in the ASF Incubator: http://incubator.apache.org/lokahi/ You can also check http://www.smartfrog.org/ -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do people handle installers/exe/bat/sh in maven?
Hi, I use 2 installers: * IzPack to generate a generic JAR installer * launch4j to wrap the generic JAR installer into an EXE for windows platforms I got the IzPack maven plugin from http://jira.codehaus.org/browse/ MOJO-277 which I installed in my custom remo repo. For launch4j I simply used its Ant task that I called using the AntRun plugin. To see how it's done check the XWiki sources here: http://svn.xwiki.org/svnroot/xwiki/xwiki-products/xwiki-enterprise/ trunk/installers/ My next step is to have a look at the daemon plugin from Apache since this plugin seem to support various installers and in additions allows starting your app as a daemon. Some pointers: http://mail-archives.apache.org/mod_mbox/directory-commits/ 200602.mbox/[EMAIL PROTECTED] http://repo1.maven.org/maven2/org/apache/directory/daemon/daemon- plugin/1.1.1/ http://svn.apache.org/viewvc/directory/trunks/daemon/installers- plugin/pom.xml?view=logpathrev=374299 http://svn.apache.org/viewvc/incubator/felix/sandbox/akarasulu/ mavenized/installers/pom.xml?revision=383421view=markuppathrev=383421 If someone gets this to work fine it would be nice to report it here. Thanks -Vincent On Oct 2, 2007, at 1:28 PM, Wim Deblauwe wrote: Hi, I have a question for the people that use maven to create an application (as opposed to a library). How do you provide an easy start point for your application? Do you use webstart? Do you use the assembly plugin and add .bat and .sh files to it? Do you create an installer (with a maven plugin)? Something else you use? regards, Wim -- Vigilog - an open source log file viewer: http:// vigilog.sourceforge.net Blog: http://www.jroller.com/page/Fester - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do people handle installers/exe/bat/sh in maven?
On Oct 2, 2007, at 4:10 PM, Wim Deblauwe wrote: For launch4j I simply used its Ant task that I called using the AntRun plugin. Good idea, I current use the maven plugin ( http://9stmaryrd.com/tools/launch4j-maven-plugin), but it is not maintained anymore it seems. Right. I looked at it too and decided it was just simpler to use AntRun... -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Clover 2 Plugin 3.0-beta-4 Released
Hi Tom, Congrats for this first release under the Atlassian umbrella! Where can we see what's different from the last version of the Clover plugin located at Apache? I tried checking http://developer.atlassian.com/jira/browse/CLMVN? report=com.atlassian.jira.plugin.system.project:changelog-panel but there's only a 3.0 beta 1 version listed and it has no issues in it. I think this information might be useful for users interested in switching for the current version to this new version. Thanks -Vincent On Sep 24, 2007, at 7:00 AM, Tom Davies wrote: Atlassian has released a new version of the maven-clover-plugin for use with Clover 2.0b2. The plugin remains open source under the Apache license. The plugin facilitates the creation of test coverage reports for projects built with Maven 2. There is an overview of the new features of Clover 2 at http:// www.atlassian.com/software/clover/whats-new.jsp Note that this version does not include an evaluation license -- you will need to download one from http://www.atlassian.com/ software/clover/GenerateCloverEvaluationLicense!default.jspa The groupId has changed, and at present the plugin is only available from Atlassian's repository. Please see http://confluence.atlassian.com/x/K4CDBQ for information on usage, bug reporting and source code location. Thanks, Tom Davies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the Best practice for generating variations of an artifacts?
Good summary of the different options Franz!
For the moment I'm happy with the solution I have found but I may
revisit it in the future, who knows.
For those interested here's a working example:
svn checkout svn://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk/web
Check the web/standard/pom.xml file and the web/exo/pom.xml one.
-Vincent
On Apr 23, 2007, at 2:09 AM, franz see wrote:
Good day,
What remote resources plugin does is that it extracts the resources
from a
specified artifact, into ${basedir}/target/maven-shared-archive-
resources.
And add those resources to your build's list of resources.
* [Filtering of remote resources]: Yes, it is possible to do so. It
uses
velocity for its filtering ( see [1] )
* [Need for a common stuff module]: Yes, but I don't see any
problems with
this. All you're doing is transferring all your common stuffs to
another
module so that others may be able to reuse themJust like
extracting a
class :-)
* [A LOT of build modules]: Yes, but the alternative is one big maven
project with LOTS of profiles.
* [More Complex Build]: Yes, in a way it is since remote resources is
relatively new and more people are more familiar with profiles than
the
remote resources plugin. But IMHO, it's not that hard to understand.
Furthermore, although you will end up with quite a number of
modules, at
least your single project ( especially your pom ) will not be
gigantic.
* [Number of Variations]: Instead of defining a variation in a
profile,
define it as a resource module. Then instead of doing a mvn install
-Pmysql,tomcat,cluster, you will now have a maven project that will
retrieve
the remote resource from your mysql-resources, tomcat-resources, and
cluster-resources.
Main Differences
* [Do you need more than one variation at a time?] If in the end,
you only
want to produce one artifact variation, then profiles would be
sufficient.
But if you need to produce more than one artifact variation, then I
suggest
you use this approach.
* [What do you prefer - one huge project, or several small
projects?] If you
use the profiles approach, the more variations you add up, the
bigger your
project becomes. However, if you use the remote resource approach,
the more
variations you add up, the more modules you will have. As to which
one is
better - I am not really sure :-) Probably, it's just a matter of
preference.
Regarding the better approach?
hmmok, maybe this is not the better approach :-) This is
actually just
an alternative that I prefer. With this approach, you'd be able to
build one
variation, or if the need arises, several variations ( although you
can do
that as well with profiles + CI, AFAIK, you'd only be able to
deploy only
one variation ). Moreover, I prefer several small projects than a
single big
one :-)
Cheers,
Franz
[1]
http://maven.apache.org/plugins/maven-remote-resources-plugin/
process-mojo.html#properties
vmassol wrote:
Hi Franz,
On Apr 20, 2007, at 4:50 AM, franz see wrote:
Good day,
If the only thing different with the variations are the config
files and
some dependencies, then I suggest you use #2.
Thanks for your help. How is #2 better than the solution I'm now
using (which used the assembly plugin to generate the WAR with the
proper files and dependencies)?
It seems to me solution #2 has the following cons:
* It's more complex in term of build and requires more effort,
maintenance and require more effort to explain.
* There's a need for having a module for common stuff.
* How do you share a common configuration (say a properties file)
that only differs in some properties? In the latest solution I've
found I simply use Maven properties or filter files. Does the remote
resources plug in allow filtering of files when they're copied? If so
that solves this issue.
* Solution #2 doesn't scale with the number of variations. Imagine
that variations are a combination of: database configurations, app
server configuration, some other configuration. Imagine that we want
to support 4 databases, 5 containers and 2 variation of the other
configuration. that's a LOT of variations and would mean a lot of
build modules, whereas with my current solution it's very simple and
only requires one profile for each database, one profile for each
appserver and one profile for the other type of configuration. Then
it's up to the user to pick the profiles he wants to use. For
example: mvn clean install -Pmysql,tomcat,cluster.
The advantage of solution #2 would be to generate all variations in
one build rather than running several times the same build with a
different profile. As this would be time consuming, we'd need
profiles anyway for normal use and for CI use (where we'd want
everything generated). This is the main difference I can see.
Anything I'm missing? :)
Thanks again for this interesting discussion
-Vincent
With regards to the shared
resources, you can do that now with the
[ANN] Clover plugin v2.4 released
The Maven team is pleased to announce the release of the Maven Clover plugin, version 2.4. You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clover-plugin/artifactId version2.4/version /plugin Here are the release notes for 2.4: ** Bug * [MCLOVER-45] - Excluded files should be added to compiled sources * [MCLOVER-53] - Clover plugin installs clover instrumented source in local repository * [MCLOVER-66] - The report goal doesn't support a user-provided Clover license * [MCLOVER-68] - XDoclet plugin executes before the Clover plugin in the lifecycle forked by the latter ** Improvement * [MCLOVER-38] - Allow check Mojo to be overriden by a failOnViolation parameter in the same way PMD and Checkstyle can * [MCLOVER-65] - Clover license has expired ** Task * [MCLOVER-67] - Remove deprecated licenseFile configuration parameter Enjoy! -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the Best practice for generating variations of an artifacts?
Hi Franz, On Apr 20, 2007, at 4:50 AM, franz see wrote: Good day, If the only thing different with the variations are the config files and some dependencies, then I suggest you use #2. Thanks for your help. How is #2 better than the solution I'm now using (which used the assembly plugin to generate the WAR with the proper files and dependencies)? It seems to me solution #2 has the following cons: * It's more complex in term of build and requires more effort, maintenance and require more effort to explain. * There's a need for having a module for common stuff. * How do you share a common configuration (say a properties file) that only differs in some properties? In the latest solution I've found I simply use Maven properties or filter files. Does the remote resources plug in allow filtering of files when they're copied? If so that solves this issue. * Solution #2 doesn't scale with the number of variations. Imagine that variations are a combination of: database configurations, app server configuration, some other configuration. Imagine that we want to support 4 databases, 5 containers and 2 variation of the other configuration. that's a LOT of variations and would mean a lot of build modules, whereas with my current solution it's very simple and only requires one profile for each database, one profile for each appserver and one profile for the other type of configuration. Then it's up to the user to pick the profiles he wants to use. For example: mvn clean install -Pmysql,tomcat,cluster. The advantage of solution #2 would be to generate all variations in one build rather than running several times the same build with a different profile. As this would be time consuming, we'd need profiles anyway for normal use and for CI use (where we'd want everything generated). This is the main difference I can see. Anything I'm missing? :) Thanks again for this interesting discussion -Vincent With regards to the shared resources, you can do that now with the maven-remote-resources- plugin. So you now have something like... . |-- core `-- variations |-- variation-a |-- variation-b |-- variation-c : `-- variation-z wherein your core has the common resource as well. Then you just bundle up core, and process it in the variation-xxx. Cheers, Franz vmassol wrote: Hi, I've never found a good answer to this use case so far so I'm curious about how others have implemented it. Imagine a project that generates a WAR. This WAR contains a config file (say in WEB-INF/classes) that configures connection parameters for the database. Now imagine that your project wants to support several databases and you want the ability to build for a given database. I see 2 options: Option 1 --- * Use filtering * Use profiles to set the values for the different databases Issues: * In order to differentiate the generate WAR file name you'll need to use finalName but the value set there won't be used for install/ deploy which means that the WAR files users will see will always be the same. Idea for future: * It would be nice if Maven had a classifier element under project so that it would be possible to generate an artifact with a classifier. Option 2 --- * Create one module per database, under a parent module * Create profiles in the parent module to conditionally include the module to be built Issues: * Very heavy (one module per database) especially when the only difference between the generated artifacts is only 3 lines in a config file * Need a way to share common configuration between the modules, in order to prevent duplication. For example if the config files only contains 3 lines that are different for each database and there are 100 lines in total, you don't want to duplicate the 97 lines in as many modules as you have databases What do people do? Is there some plan to support this use case in a better fashion in the future? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the Best practice for generating variations of an artifacts?
Hi John and everyone,
Sorry for answering you so late on this and thanks again for your
feedback.
Following your direction I think I've found something slightly better:
* I use a pom packaging
* I use the assembly plugin to directly generate a WAR using the
following assembly descriptor:
assembly
id${xwiki.db}/id
formats
formatwar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectoryWEB-INF/lib/outputDirectory
/dependencySet
/dependencySets
fileSets
fileSet
directory${basedir}/src/main/webapp/directory
outputDirectory//outputDirectory
/fileSet
/fileSets
files
file
source${basedir}/src/main/resources/hibernate.cfg.xml/source
outputDirectoryWEB-INF//outputDirectory
filteredtrue/filtered
/file
/files
/assembly
* ${xwiki.db} is defined in the pom.xml in each profile
* hibernate.cfg.xml contains properties defined in each profile. I
could also use a filter file but it's not necessary in this example
I'm currently happy with this solution (need to test further though
as I've just tried it and was excited to have found something that
seems to work) except that I find it strange to have to declare my
packaging to be pom when all I want to generate is a war...
I'll post back when I have finished implementing and testing this
solution.
Thanks
-Vincent
On Mar 16, 2007, at 8:19 PM, John J. Franey wrote:
I came up with a third path. Mutliple projects, but with a slight
difference.
In the base project, an assembly would create an archive of unfiltered
configuration files. So the base project has the war (or jar) and
a zip of
unfiltered configuration files. This project does not put any app
server
specific configuration files in its output.
In the assembly projects, use dependency plugin to unpack the
unfiltered
configuration files from the base project. Use assembly plugin to
reassemble, filter (too bad assembly-plugin doesn't support FileSet
filtering in 2.2-SNAPSHOT today). Mixin app server specific
configuration
files.
I put a filtered property in the assembly id to distinguish
archives built
with different profiles. The assembly plugin uses the assembly id
in the
name of the archives.
Drive multiple builds of the same assembly project for each set of
profiles
you define. At the end, target contains an archive for each
unique use of
the assembly Id property. This is done manually or with a shell
script.
Maybe this is the core issue you are addressing. I didn't think
maven did
any iteration like this.
The advantages of this approach:
App server specific configuration details (e.g. tomcat
context.xml) are
isolated from common j2ee configuration (web.xml). The base
project is not
laden with server specific configuration details. Unit level
developer is
can tweak his runtime more freely.
Disadvantge:
The configurable properties set in the base project must be
propagated up to
the assembly projects so that they are correctly set. This is a
nuisance.
John
--
View this message in context: http://www.nabble.com/What-is-the-
Best-practice-for-generating-variations-of-an-artifacts--
tf3414040s177.html#a9520819
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can i run clover and cobertura permanantly?
Hi, On Mar 25, 2007, at 11:47 PM, Baz wrote: Hi, How can I run test code coverage tools as part of my build? What changes do i need to make in the pom.xml? I ran mvn cobertura:cobertura and seems like it is generating the reports. Please advise. You can check the plugin documentation for example :) http://maven.apache.org/plugins/index.html -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is the Best practice for generating variations of an artifacts?
Hi, I've never found a good answer to this use case so far so I'm curious about how others have implemented it. Imagine a project that generates a WAR. This WAR contains a config file (say in WEB-INF/classes) that configures connection parameters for the database. Now imagine that your project wants to support several databases and you want the ability to build for a given database. I see 2 options: Option 1 --- * Use filtering * Use profiles to set the values for the different databases Issues: * In order to differentiate the generate WAR file name you'll need to use finalName but the value set there won't be used for install/ deploy which means that the WAR files users will see will always be the same. Idea for future: * It would be nice if Maven had a classifier element under project so that it would be possible to generate an artifact with a classifier. Option 2 --- * Create one module per database, under a parent module * Create profiles in the parent module to conditionally include the module to be built Issues: * Very heavy (one module per database) especially when the only difference between the generated artifacts is only 3 lines in a config file * Need a way to share common configuration between the modules, in order to prevent duplication. For example if the config files only contains 3 lines that are different for each database and there are 100 lines in total, you don't want to duplicate the 97 lines in as many modules as you have databases What do people do? Is there some plan to support this use case in a better fashion in the future? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the Best practice for generating variations of an artifacts?
Hi Jeff,
On Mar 16, 2007, at 1:00 PM, Jeff Jensen wrote:
I do my best to avoid needing a separate build per environment. A
release
is a release, and while reproducibility is not the issue, I find it
silly to
do so.
In my customer work, I found two key strategies that have worked
well, both
from new system and streamlining an existing system:
Option 3
Use container configuration. Just get the DataSource for a
connection. For
other info, set properties and/or servlet context params.
You're just moving the problem elsewhere! :)
You'll still need to configure those datasources in your container
config file.
Option 4
Include all property files in the artifact, and the environment
determines
which one is used:
- Have a base name for the set of property files, e.g.
app.properties.
- Set an environment variable on each runtime environment, e.g.
APP_ENV=dev, APP_ENV=test, APP_ENV=prod.
- Have the code load props from app_${APP_ENV}.properties. Or use
the env
var as a directory name for a collection of env specific files, e.g.
${APP_ENV}/app.properties.
I don't like this approach too much as:
1) the app becomes bloated. For example it means adding the MySQL +
HSQL DB + Oracle + PostGreSQL driver jars It starts to add up...
2) it's not as nice for the end user as you need to explain to him
that he needs to set some env variable, etc, whereas in the approach
where you make the different distributions available, he just picks
the one he wants and it works out of the box
Thanks for your inputs!
-Vincent
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 6:39 AM
To: Maven Users List
Subject: What is the Best practice for generating variations of an
artifacts?
Hi,
I've never found a good answer to this use case so far so I'm
curious about
how others have implemented it.
Imagine a project that generates a WAR. This WAR contains a config
file (say
in WEB-INF/classes) that configures connection parameters for the
database.
Now imagine that your project wants to support several databases
and you
want the ability to build for a given database.
I see 2 options:
Option 1
---
* Use filtering
* Use profiles to set the values for the different databases
Issues:
* In order to differentiate the generate WAR file name you'll need
to use
finalName but the value set there won't be used for install/
deploy which
means that the WAR files users will see will always be the same.
Idea for future:
* It would be nice if Maven had a classifier element under
project so
that it would be possible to generate an artifact with a classifier.
Option 2
---
* Create one module per database, under a parent module
* Create profiles in the parent module to conditionally include the
module
to be built
Issues:
* Very heavy (one module per database) especially when the only
difference
between the generated artifacts is only 3 lines in a config file
* Need a way to share common configuration between the modules, in
order to
prevent duplication. For example if the config files only contains
3 lines
that are different for each database and there are 100 lines in
total, you
don't want to duplicate the 97 lines in as many modules as you have
databases
What do people do? Is there some plan to support this use case in a
better
fashion in the future?
Thanks
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the Best practice for generating variations of an artifacts?
On Mar 16, 2007, at 1:20 PM, Kenney Westerhof wrote: Hi, Vincent Massol wrote: Hi, I've never found a good answer to this use case so far so I'm curious about how others have implemented it. Imagine a project that generates a WAR. This WAR contains a config file (say in WEB-INF/classes) that configures connection parameters for the database. Now imagine that your project wants to support several databases and you want the ability to build for a given database. I see 2 options: Option 1 --- * Use filtering * Use profiles to set the values for the different databases Issues: * In order to differentiate the generate WAR file name you'll need to use finalName but the value set there won't be used for install/deploy which means that the WAR files users will see will always be the same. You could use the buildhelper-maven-plugin or the assembly plugin to attach the artifact with a classifier. You can also configure the jar/war plugins with a classifier element. ok will check all these out, thanks. Idea for future: * It would be nice if Maven had a classifier element under project so that it would be possible to generate an artifact with a classifier. That's not an option. The pom is shared between all artifacts, both primary and all secondary attachments. The main artifact is always without a classifier. Option 2 --- * Create one module per database, under a parent module * Create profiles in the parent module to conditionally include the module to be built Issues: * Very heavy (one module per database) especially when the only difference between the generated artifacts is only 3 lines in a config file * Need a way to share common configuration between the modules, in order to prevent duplication. For example if the config files only contains 3 lines that are different for each database and there are 100 lines in total, you don't want to duplicate the 97 lines in as many modules as you have databases What do people do? Is there some plan to support this use case in a better fashion in the future? This is typically solved in several different ways, depending on the role a person has in the team. Standard j2ee practices etc. recommend a 'deployment manager' to either edit WEB-INF/web.xml before deploying, or as an alternative, a 'system manager' will provide you with the name of a JNDI Datasource configured in tomcat's server.xml (or whatever container is used). This latter approach is best since it won't require any modifications to the war. You're just pushing the pb as Tomcat would need to be configured too, so the WAR would be the same (good) but the module that generates the container zip/install would have the same issue. And if we tell the users that they need to have a correct configuration then it's not good enough. What I'm trying to provide is an out of the box solution so that users download a zip, they expand it and it just works. Of course there are still some dependencies to the environment like the need for an OS installed, a JVM, etc but the idea is to have something as easy as possible to use OOB. Also we're not using any JNDI server and to be completely generic we would need to a Generic Configuration Server used to serve configuration data to the application. But again this pushes the pb to this Configuration Server app. In the case of embedded databases or other circumstances, some other solutions could be: - split the configuration into 2 files: the common file that's the same for each 'classifier', and a database/environment specific file. The modules would then only contain the environment specific file Right. This requires some heavy lifting for the app I have in mind and is a little bit less nice for end users as right now they only have to know about a single config file and they'd need to know about several. - create the environment specific file using filtering and maven's profile mechanism Sure, but that still requires a solution for the common parts. Something like resource injection (I need to check if the remote resources plugin can do something like this) - package up just 1 war with a property file for all possible environments. Specify a system property or a configuration file or JNDI property that contains the name of the type of environment, and let the webapp load the appropriate property file. Downside is that you cannot use the automatic mechanism of the db provider to load the property file, but you have to supply it in code. Yep this was what Jeff suggested too but again it's less nice for the end user. I'd go with either profiles for different environments, or just use settings.xml with some properties that need to be configured (so that developers themselves can choose wheter 1 profile is sufficient, or create multiple profiles for different environments). If the only data you want to change
Re: Code coverage with AspectJ?
On Mar 9, 2007, at 11:58 PM, Kaare Nilsen wrote: On 09/03/07, Vincent Massol [EMAIL PROTECTED] wrote: On Mar 9, 2007, at 2:16 PM, Steve Shucker wrote: I don't think AspectJ and Clover are compatible. Hmmm they might be if you run them in the right order. Run Clover first on sources and then AspectJ on either generated sources or on the JAR. This should work I think, although I don't recall having tried this. Don't think it is possible even if you run aspectJ on the generated source. All the references I am able to find on the net says it's not possible, and this is also my own experience Can you explain why it's not possible in a few words? Thanks -Vincent We use Cobertura instead. The coverage report isn't as nice, but it is functional. For maven1, there's also an emma plugin. -Steve Michael Waluk wrote: Hi, I can't find much else regarding using AspectJ with Clover. Were you able to get it working with an example AspectJ project? Has anyone been successful with this yet? We have it to the point where we are getting 0% coverage for some reason, but I haven't spent much time on it. I'd bother if there were some success stories out there. Thanks for any info, Michael On 7/26/06, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Kaare Nilsen [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 19:53 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 26/07/06, Jason Chaffee [EMAIL PROTECTED] wrote: I use cobetura and load-time weaving during unit-tests to do this. To use load-time weaving you must fork at least once and provide the javaagent as an argline -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 8:42 AM To: 'Maven Users List' Subject: RE: Code coverage with AspectJ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: mercredi 26 juillet 2006 17:29 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 7/26/06, Howard Lewis Ship [EMAIL PROTECTED] wrote: Does anyone know how to generate a code coverage report when using AspectJ in a project? The Clover plugin wants to rewrite and recompile the code, which probably won't play well with all things aspect. seems not possible: [quote] Indeed running AspectJ AFTER Clover works. I'm using that for now, so that I at least have SOME Clover data. The thing I would like though, is to run AspectJ BEFORE Clover runs, so I also have Clover data on the AspectJ-sources! As I see it, there are 2 ways to do this: 1) AspectJ weaves his new files and writes them out as sources so Clover can work on them. The problem here will be that Clover can't show the reports on AspectJ-files, but rather on the weaved files. Why not? If you point the Clover plugin to the generated sources it should work fine, no? I guess I'd need to try it. It's a solution, but what would be really great is: 2) Clover examines the AspectJ sources and adds his statements to those files. Then AspectJ can do his normal thing and Clover's reports should show the coverage in the correct files and calculate the EXACT amount of times the statements have been called. I don't understand this solution. Is clover running before aspectj in this case? If so then we're back to the first solution above, no? Unfortunately I already heard from Cenqua that atm Clover doesn't know how to handle AspectJ sources... So I think that the plugin will have the same problems... Ah maybe there's some issue. If someone could show me a very simple aspectj project (one simple class, one aspect, one test and a POM using the aspectj plugin) then I could add it to the clover plugin's test suite and try it out. You will find some here : http://svn.codehaus.org/mojo/trunk/mojo/aspectj-maven- plugin/src/test/projects/ But as Carlos mentioned. Clover and aspectJ is not really compatible Thanks for the link. Could you elaborate just a little more about the incompatibility before I spend too much time looking into it? :-) Thanks -Vincent Is there a Maven2 plugin for emma or cobetura? cobertura, and it plays well with aspectj afaik, you have to make sure the aspectj plugin doesn't recompile from sources for what I read in the cobertura mailing list -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
Re: Code coverage with AspectJ?
On Mar 10, 2007, at 10:44 AM, Kaare Nilsen wrote: AFAIK this is still valid : http://www.cenqua.com/forums/thread.jspa?messageID=13711#13711 But this not what I said... I explicitely mentioned that you have to run them in the right order... See my message below :) -Vincent On 10/03/07, Vincent Massol [EMAIL PROTECTED] wrote: On Mar 9, 2007, at 11:58 PM, Kaare Nilsen wrote: On 09/03/07, Vincent Massol [EMAIL PROTECTED] wrote: On Mar 9, 2007, at 2:16 PM, Steve Shucker wrote: I don't think AspectJ and Clover are compatible. Hmmm they might be if you run them in the right order. Run Clover first on sources and then AspectJ on either generated sources or on the JAR. This should work I think, although I don't recall having tried this. Don't think it is possible even if you run aspectJ on the generated source. All the references I am able to find on the net says it's not possible, and this is also my own experience Can you explain why it's not possible in a few words? Thanks -Vincent We use Cobertura instead. The coverage report isn't as nice, but it is functional. For maven1, there's also an emma plugin. -Steve Michael Waluk wrote: Hi, I can't find much else regarding using AspectJ with Clover. Were you able to get it working with an example AspectJ project? Has anyone been successful with this yet? We have it to the point where we are getting 0% coverage for some reason, but I haven't spent much time on it. I'd bother if there were some success stories out there. Thanks for any info, Michael On 7/26/06, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Kaare Nilsen [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 19:53 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 26/07/06, Jason Chaffee [EMAIL PROTECTED] wrote: I use cobetura and load-time weaving during unit-tests to do this. To use load-time weaving you must fork at least once and provide the javaagent as an argline -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 8:42 AM To: 'Maven Users List' Subject: RE: Code coverage with AspectJ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: mercredi 26 juillet 2006 17:29 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 7/26/06, Howard Lewis Ship [EMAIL PROTECTED] wrote: Does anyone know how to generate a code coverage report when using AspectJ in a project? The Clover plugin wants to rewrite and recompile the code, which probably won't play well with all things aspect. seems not possible: [quote] Indeed running AspectJ AFTER Clover works. I'm using that for now, so that I at least have SOME Clover data. The thing I would like though, is to run AspectJ BEFORE Clover runs, so I also have Clover data on the AspectJ-sources! As I see it, there are 2 ways to do this: 1) AspectJ weaves his new files and writes them out as sources so Clover can work on them. The problem here will be that Clover can't show the reports on AspectJ-files, but rather on the weaved files. Why not? If you point the Clover plugin to the generated sources it should work fine, no? I guess I'd need to try it. It's a solution, but what would be really great is: 2) Clover examines the AspectJ sources and adds his statements to those files. Then AspectJ can do his normal thing and Clover's reports should show the coverage in the correct files and calculate the EXACT amount of times the statements have been called. I don't understand this solution. Is clover running before aspectj in this case? If so then we're back to the first solution above, no? Unfortunately I already heard from Cenqua that atm Clover doesn't know how to handle AspectJ sources... So I think that the plugin will have the same problems... Ah maybe there's some issue. If someone could show me a very simple aspectj project (one simple class, one aspect, one test and a POM using the aspectj plugin) then I could add it to the clover plugin's test suite and try it out. You will find some here : http://svn.codehaus.org/mojo/trunk/mojo/aspectj-maven- plugin/src/test/projects/ But as Carlos mentioned. Clover and aspectJ is not really compatible Thanks for the link. Could you elaborate just a little more about the incompatibility before I spend too much time looking into it? :-) Thanks -Vincent Is there a Maven2 plugin for emma or cobetura? cobertura, and it plays
Re: Code coverage with AspectJ?
On Mar 9, 2007, at 2:16 PM, Steve Shucker wrote: I don't think AspectJ and Clover are compatible. Hmmm they might be if you run them in the right order. Run Clover first on sources and then AspectJ on either generated sources or on the JAR. This should work I think, although I don't recall having tried this. -Vincent We use Cobertura instead. The coverage report isn't as nice, but it is functional. For maven1, there's also an emma plugin. -Steve Michael Waluk wrote: Hi, I can't find much else regarding using AspectJ with Clover. Were you able to get it working with an example AspectJ project? Has anyone been successful with this yet? We have it to the point where we are getting 0% coverage for some reason, but I haven't spent much time on it. I'd bother if there were some success stories out there. Thanks for any info, Michael On 7/26/06, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Kaare Nilsen [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 19:53 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 26/07/06, Jason Chaffee [EMAIL PROTECTED] wrote: I use cobetura and load-time weaving during unit-tests to do this. To use load-time weaving you must fork at least once and provide the javaagent as an argline -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 8:42 AM To: 'Maven Users List' Subject: RE: Code coverage with AspectJ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: mercredi 26 juillet 2006 17:29 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 7/26/06, Howard Lewis Ship [EMAIL PROTECTED] wrote: Does anyone know how to generate a code coverage report when using AspectJ in a project? The Clover plugin wants to rewrite and recompile the code, which probably won't play well with all things aspect. seems not possible: [quote] Indeed running AspectJ AFTER Clover works. I'm using that for now, so that I at least have SOME Clover data. The thing I would like though, is to run AspectJ BEFORE Clover runs, so I also have Clover data on the AspectJ-sources! As I see it, there are 2 ways to do this: 1) AspectJ weaves his new files and writes them out as sources so Clover can work on them. The problem here will be that Clover can't show the reports on AspectJ-files, but rather on the weaved files. Why not? If you point the Clover plugin to the generated sources it should work fine, no? I guess I'd need to try it. It's a solution, but what would be really great is: 2) Clover examines the AspectJ sources and adds his statements to those files. Then AspectJ can do his normal thing and Clover's reports should show the coverage in the correct files and calculate the EXACT amount of times the statements have been called. I don't understand this solution. Is clover running before aspectj in this case? If so then we're back to the first solution above, no? Unfortunately I already heard from Cenqua that atm Clover doesn't know how to handle AspectJ sources... So I think that the plugin will have the same problems... Ah maybe there's some issue. If someone could show me a very simple aspectj project (one simple class, one aspect, one test and a POM using the aspectj plugin) then I could add it to the clover plugin's test suite and try it out. You will find some here : http://svn.codehaus.org/mojo/trunk/mojo/aspectj-maven- plugin/src/test/projects/ But as Carlos mentioned. Clover and aspectJ is not really compatible Thanks for the link. Could you elaborate just a little more about the incompatibility before I spend too much time looking into it? :-) Thanks -Vincent Is there a Maven2 plugin for emma or cobetura? cobertura, and it plays well with aspectj afaik, you have to make sure the aspectj plugin doesn't recompile from sources for what I read in the cobertura mailing list -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: Cargo maven 2 plugin : timeout when deploying to JBoss 4x
Hi Guillaume,
On Feb 22, 2007, at 4:29 PM, Guillaume Duchesneau wrote:
Hi,
We are in the process of creating an integration test suite for a J2EE
project using the Cargo Maven 2 plugin with a JBoss 4.0 container.
When
we execute mvn integration-test, the jboss zip is correctly
expanded and
our war is copied at the right place. The problem we have is that our
application takes more than 20 seconds to deploy and Cargo throws an
exception saying that the timeout is exceeded. I do not see any
configuration that can override the timeout for a deployable... is
there
one? Or is there any workaround for that kind of problem?
This would be best posted on the cargo lists...
Yes there are ways to set the timeout. See http://cargo.codehaus.org/
Maven2+Plugin+Reference+Guide
Also, is there a way to tell to the installer (zipUrlInstaller) to
force
a cleanup and a full reinstall (i.e. delete the install dir and
re-expand the zip file)?
No but I don't understand why this would be needed. Could you please
post any further questions on the cargo lists?
Thanks
-Vincent
Here is our plugin config in the pom.xml:
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
configuration
waitfalse/wait
container
containerIdjboss4x/containerId
zipUrlInstaller
urlfile:///${jboss.distribution.dir}/JBoss4.0.zip/url
installDir${installDir}/installDir
/zipUrlInstaller
log${log.dir}/cargo.log/log
output${log.dir}/jboss.log/output
/container
configuration
typeexisting/type
home${installDir}/jboss/server/default/home
/configuration
/configuration
executions
execution
idstart-container/id
phasepre-integration-test/
phase
goals
goalstart/goal
goaldeploy/goal
/goals
configuration
deployer
deployables
deployable
groupIdorg.xyz/groupId
artifactIdmy-app/artifactId
typewar/type
pingURLhttp://localhost:8080/index.jsf/pingURL
/deployable
/deployables
/deployer
/configuration
/execution
execution
idstop-container/id
phasepost-integration-test/
phase
goals
goalstop/goal
/goals
/execution
/executions
/plugin
Here is the error trace:
[INFO]
--
--
[INFO] Deployable failed to finish deploying within the timeout period
[2]. The Deployable state is thus unknown.
[INFO]
--
--
[INFO] Trace
org.codehaus.cargo.container.ContainerException: Deployable failed to
finish deploying within the timeout period [2]. The Deployable
state
is thus unknown.
at
org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch
(Deploye
rWatchdog.java:109)
at
org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watchForAva
il
ability(DeployerWatchdog.java:78)
at
org.codehaus.cargo.container.spi.deployer.AbstractLocalDeployer.deploy
(A
bstractLocalDeployer.java:98)
at
org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSi
ng
leDeployable(DeployerDeployMojo.java:75)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOn
Al
lDeployables(AbstractDeployerMojo.java:106)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.execute
(AbstractDeployerM
ojo.java:43)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginMa
nager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Default
LifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif
ec
ycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultL
ifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand
le
Failures(DefaultLifecycleExecutor.java:306)
Re: Cargo undeploy error
Hi Jelle, Could you use the 0.3-SNAPSHOT version (we've fixed that in there). See http://cargo.codehaus.org/Maven2+Plugin+Installation Thanks -Vincent PS: Next time, please use the cargo mailing lists. On Feb 6, 2007, at 9:13 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I'm exploring the possibilities of the Maven cargo plugin to deploy my projects on a remote Apache Tomcat server. I've created a small web project that contains a simple .html file with some info on it. I packaged it as a WAR so I can deploy it on my server. Now I made a cargo configuration in my project's pom. Deploying works just fine, but when I want to undeploy the web project, I get a weird error. Just like the undeploy goal isn't supported. I've already checked the version of the maven-cargo-plugin, but everutihing seems ok to me. Cargo: deploy works fine as you can see But when I try to undeploy my war, I get the following error. C:\eGovDev\cargo-testmvn cargo:deploy [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'cargo'. [INFO] -- -- - --- [INFO] Building cargo-test [INFO]task-segment: [cargo:deploy] [INFO] -- -- - --- [INFO] [cargo:deploy] [INFO] -- -- [INFO] BUILD SUCCESSFUL [INFO] -- -- [INFO] Total time: 8 seconds [INFO] Finished at: Tue Feb 06 09:08:28 CET 2007 [INFO] Final Memory: 3M/8M [INFO] -- -- C:\eGovDev\cargo-testmvn cargo:undeploy [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'cargo'. [INFO] -- -- - --- [INFO] Building cargo-test [INFO]task-segment: [cargo:undeploy] [INFO] -- -- - --- [INFO] [cargo:undeploy] [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] Not supported [INFO] -- -- [INFO] Trace org.codehaus.cargo.container.ContainerException: Not supported at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.undeploy(A bstractDeployer.java:99) at org.codehaus.cargo.maven2.DeployerUndeployMojo.performDeployerActionO nSingleDeployable(DeployerUndeployMojo.java:39) at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionO nAllDeployables(AbstractDeployerMojo.java:104) at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDepl oyerMojo.java:47) at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo .java:243) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] -- -- [INFO] Total time: 7 seconds [INFO] Finished at: Tue Feb 06 09:08:57 CET 2007 [INFO] Final Memory: 3M/8M [INFO]
Re: Maven 2.0 Plugin for ZIP Archive
On Jan 28, 2007, at 9:08 AM, LAMY Olivier wrote: http://jira.codehaus.org/browse/MNG-1683 Yep this is the 9th most popular issue (http://jira.codehaus.org/ browse/MNG? report=com.atlassian.jira.plugin.system.project:popularissues-panel). And BTW IMO the assembly plugin for this is a hack (at least in the way it's currently implemented but I believe it can be modified to support the zip use case). -Vincent -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : dimanche 28 janvier 2007 00:12 À : users@maven.apache.org Objet : Maven 2.0 Plugin for ZIP Archive I am looking for a Maven 2.0 plugin that would help me prepare a ZIP archive. From Maven 2.0.4 documentation, it appears that .zip archives are not supported. Regards, /U - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven 2, clover and contexts
Hi David,
I think the reason is because the contextFilter configuration
element is a property of the report mojo and thus it needs to be
defined in the reporting section and not in the build section.
For example:
reporting
excludeDefaultstrue/excludeDefaults
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
!-- Verify that context filters work --
contextFilterstry/contextFilters
/configuration
/plugin
/plugins
/reporting
Let me know if this works for you and I'll update the documentation.
Thanks
-Vincent
On Jan 18, 2007, at 11:07 PM, c_inconnu2 wrote:
Hi Vincent,
Thanks for your answer. Indeed there is no reason that it should
work : I was just wondering...
But I tried to use contextFilters and I cannot manage to get it
work either. Here is a part of my pom :
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
/plugin
/plugins
/reporting
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
showDeprecationtrue/showDeprecation
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
jdk1.5/jdk
contextFilterstry/contextFilters
/configuration
executions
execution
phasepre-site/phase
goals
goalinstrument/goal
/goals
/execution
/executions
/plugin
/plugins
/build
I tested with this :
public static String f()
{
try
{
if(true){
Class.forName(AAA);}
Class.forName(BBB);
}
catch (Exception e)
{
// TODO: handle exception
}
return f;
}
If I understand, the line Class.forName(BBB); should be reported
as not tested ???
But it is in red in the report (statement not executed). And
Class.forName(AAA); was executed
Thanks for your help
Vincent Massol a écrit :
Hi David,
Why are you assuming that statementContext would work?
Just check the plugin documentation and you'll see that the
correct tag name is contextFilters. Just check the documentation
for more details and examples.
Thanks
-Vincent
On Jan 17, 2007, at 11:46 PM, c_inconnu2 wrote:
Hi,
I am trying to configure Clover to use contextFilters with
statementContext. Here is my pom.xml :
reporting
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
jdk1.5/jdk
excludes
exclude**/*AllTests.java/exclude
exclude**/*Main.java/exclude
exclude**/*Main$*.java/exclude
exclude**/*Test.java/exclude
exclude**/*Test$*.java/exclude
/excludes
statementContext name=log regexp=^logger
\..* /
!--statementContext name=iflog regexp=^if \
(logger\.is.* /--
statementContext name=iflog regexp=if.?.?
log.*\.isDebugEnabled.*} /
!--contextFilterslog,iflog/contextFilters--
contextFilterstry/contextFilters
/configuration
/plugin
...
plugins
reporting
as you can see, I tried many things. I looked the clover site,
search mailing lists but nothing...
I even looked into the plugin source code : it seems that it does
not handle statementContext.
But since even the try context does not work...
Any help will be greatly appreciated, thanks
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son
interface révolutionnaire.
http://fr.mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven 2, clover and contexts
On Jan 21, 2007, at 1:25 AM, c_inconnu2 wrote:
That works !
Documentation updated.
Thanks for your help. Is there any plan to support
statementContext in the plugin ?
We need to support it but it's not done yet. Create a JIRA issue if
it's not there already. I'll probably be able to spend some time on
the plugin end of next week.
I'd like to exclude all my loggers... BTW, I'll try to understand
how that works and see if i can contribute
Cool!
Thanks
-Vincent
David DIDIER
Vincent Massol a écrit :
Hi David,
I think the reason is because the contextFilter configuration
element is a property of the report mojo and thus it needs to be
defined in the reporting section and not in the build section.
For example:
reporting
excludeDefaultstrue/excludeDefaults
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
!-- Verify that context filters work --
contextFilterstry/contextFilters
/configuration
/plugin
/plugins
/reporting
Let me know if this works for you and I'll update the documentation.
Thanks
-Vincent
On Jan 18, 2007, at 11:07 PM, c_inconnu2 wrote:
Hi Vincent,
Thanks for your answer. Indeed there is no reason that it should
work : I was just wondering...
But I tried to use contextFilters and I cannot manage to get it
work either. Here is a part of my pom :
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
/plugin
/plugins
/reporting
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
showDeprecationtrue/showDeprecation
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
jdk1.5/jdk
contextFilterstry/contextFilters
/configuration
executions
execution
phasepre-site/phase
goals
goalinstrument/goal
/goals
/execution
/executions
/plugin
/plugins
/build
I tested with this :
public static String f()
{
try
{
if(true){
Class.forName(AAA);}
Class.forName(BBB);
}
catch (Exception e)
{
// TODO: handle exception
}
return f;
}
If I understand, the line Class.forName(BBB); should be
reported as not tested ???
But it is in red in the report (statement not executed). And
Class.forName(AAA); was executed
Thanks for your help
Vincent Massol a écrit :
Hi David,
Why are you assuming that statementContext would work?
Just check the plugin documentation and you'll see that the
correct tag name is contextFilters. Just check the
documentation for more details and examples.
Thanks
-Vincent
On Jan 17, 2007, at 11:46 PM, c_inconnu2 wrote:
Hi,
I am trying to configure Clover to use contextFilters with
statementContext. Here is my pom.xml :
reporting
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
jdk1.5/jdk
excludes
exclude**/*AllTests.java/exclude
exclude**/*Main.java/exclude
exclude**/*Main$*.java/exclude
exclude**/*Test.java/exclude
exclude**/*Test$*.java/exclude
/excludes
statementContext name=log regexp=^logger
\..* /
!--statementContext name=iflog
regexp=^if \(logger\.is.* /--
statementContext name=iflog regexp=if.?.?
log.*\.isDebugEnabled.*} /
!--contextFilterslog,iflog/contextFilters--
contextFilterstry/contextFilters
/configuration
/plugin
...
plugins
reporting
as you can see, I tried many things. I looked the clover site,
search mailing lists but nothing...
I even looked into the plugin source code : it seems that it
does not handle statementContext.
But since even the try context does not work...
Any help will be greatly appreciated, thanks
David
Re: maven 2, clover and contexts
Hi David, Why are you assuming that statementContext would work? Just check the plugin documentation and you'll see that the correct tag name is contextFilters. Just check the documentation for more details and examples. Thanks -Vincent On Jan 17, 2007, at 11:46 PM, c_inconnu2 wrote: Hi, I am trying to configure Clover to use contextFilters with statementContext. Here is my pom.xml : reporting plugins ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clover-plugin/artifactId configuration jdk1.5/jdk excludes exclude**/*AllTests.java/exclude exclude**/*Main.java/exclude exclude**/*Main$*.java/exclude exclude**/*Test.java/exclude exclude**/*Test$*.java/exclude /excludes statementContext name=log regexp=^logger \..* / !--statementContext name=iflog regexp=^if \ (logger\.is.* /-- statementContext name=iflog regexp=if.?.? log.*\.isDebugEnabled.*} / !--contextFilterslog,iflog/contextFilters-- contextFilterstry/contextFilters /configuration /plugin ... plugins reporting as you can see, I tried many things. I looked the clover site, search mailing lists but nothing... I even looked into the plugin source code : it seems that it does not handle statementContext. But since even the try context does not work... Any help will be greatly appreciated, thanks David ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Quality Dashboard
Well... :-) I have been wanting to write this dashboard stuff for a long time now but I've never found the time to do it... I've now joined the XWiki project and I think it would make a nice foundation for a quality/health dashboard. OTOH I still don't know when I'll have time to work on it. Don't hold your breath... That said, others on the list have already started working on a dashboard plugin and there's even been a submission for it I think. You may want to look at that. Thanks -Vincent -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: samedi 2 décembre 2006 02:08 To: Maven Users List Subject: Re: Quality Dashboard I went to a conference in Montreal today and from what Vincent said, it's going to be based on XWiki. I'll let him talk more about it by himself :) On 9/7/06, Wim Deblauwe [EMAIL PROTECTED] wrote: Hi, reading through http://idisk.maven.org/jvanzyl/Public/presos/Feynman.pdf, there is talk of Vincent's Dashboard. Is this a plugin that is going to be released soon? I think many users would like a quality dashboard that can generate graphs of your metrics (PMD, unit test pass rate, code coverage, ...) over time. regards, Wim ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-clover-plugin exclude not working
Jeff, I'll try to have a look at it today (no guarantees though). What you could investigate is to read the code and fix what's wrong! :-) I gave it a cursory look and couldn't find anything especially as several users are using the exclude mechanism and it seems to work fine for them (except for the compile bug reported today by Nick: http://jira.codehaus.org/browse/MCLOVER-62 Thanks -Vincent -Original Message- From: Jeff Mutonho [mailto:[EMAIL PROTECTED] Sent: mercredi 15 novembre 2006 07:59 To: Maven Users List Subject: Re: maven-clover-plugin exclude not working Hi guys Anyone with an idea what I could perhaps investigate? -- Jeff Mutonho Cape Town South Africa GoogleTalk : ejbengine Skype: ejbengine Registered Linux user number 366042 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Source code examples for Better Builds with Maven?
Hi Ed, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Young Sent: samedi 11 novembre 2006 20:38 To: users@maven.apache.org Subject: Source code examples for Better Builds with Maven? I went to the mergere site and the source code examples for the Better Builds book are zip file of size 0. I've emailed mergere, called (twice) and have gotten no answers. Is this source freely available, and if so, can someone point me to it? Yes it's freely available from the mergere web site but they seem to have an issue with their links... It's the weekend which is probably why you're not getting an answer. Let's hope it's fixed on Monday. Thanks -Vincent ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] cargo / codehaus mailing lists
Hi Nathan, I'm not sure if there's any other way than using xircles now... :-( I've reported the error (http://jira.codehaus.org/browse/HAUS-1373) and it's already been fixed by speedy Ben! :-) Try it now it should work. Thanks -Vincent -Original Message- From: Nathan Coast [mailto:[EMAIL PROTECTED] Sent: mercredi 8 novembre 2006 09:41 To: Maven Users Subject: [OT] cargo / codehaus mailing lists Hi, anyone know how to subscribe to the codehaus cargo mailing list? I have some maven / cargo questions but the link in the docs to the mailing list is broken :( http://xircles.codehaus.org/projects/cargo/lists cheers Nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
-Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: mardi 7 novembre 2006 09:04 To: Maven Users List Subject: Re: We need some explanation ... Hi Vincent, The architecture is quite clear now, but there remains some questions: - I understand that when calling clover:instrument in any phase, this triggers a custom lifecycle (clover LC) that runs instrumentInternal and then runs the tests so that clover DB gets populated. This lifecycle is forked so that original sources are prevented from ending up in artifact. Yes, exactly. - the original question was about the use of process-sources: It seemed to me that coverage intsrumentation should be done after all sources are generated. Why is this not the case for clover ? The clover:instrumentInternal goal is bound to the generate-sources phase (the first phase for sources). The main reason is that any source generated is usually already tested (the generators are usually tested) and there's usually no need to write tests for it. Instrumenting the generated sources would skew the coverage result. Now I agree that it's possible that there are cases where you'd want the instrumentation to include generated sources. This is not supported as of now. Actually nobody has asked for this use case yet... Thanks -Vincent ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
-Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: mardi 7 novembre 2006 11:03 To: Maven Users List Subject: Re: We need some explanation ... Thanks for the (quick :-)) answer. I agree that generated sources are usually tested and do not need specific tests, so instrumenting them may not be very useful as far as branch/line coverage is concerned. I can think however of a use case where you would need coverage of generated code. Imagine that your generator provides glue code between components/classes folloving some pattern of communication and that you want to cover with your tests the interaction between two classes. You would need instrumentation information for generated sources to link standard java method invocation in your classes with something in your glue code. This all depends on what you are trying to cover with your tests. All tools I am aware of gives you so-called branch or line coverage, but there exists different coverage information that would be often more useful to have. As I said I agree that there are valid use cases. Do you need this feature for your build? If so, please create a jira issue on the Clover plugin. You could also provide a patch if you need it. It should be quite easy I think: we'll need to create 2 new goals: One new clover:instrumentWithGeneratedSources and one clover:instrumentInternalWithGeneratesSources. It's kind of ugly but I don't currently see any other way. Thanks -Vincent ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Poor man's web.xml merging
Hi Arnaud, I haven't worked on that code so I don't know what's wrong. I do know that people are able to use it though so it's possible you could get it to work and the error may be a configuration error. I think the best would be for you to post anything related to Cargo on the Cargo user list as the author of this code is reading the emails there. He may not see it here though. Thanks -Vincent -Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: mardi 7 novembre 2006 11:05 To: Maven Users List Subject: Re: Poor man's web.xml merging Ouuup ! [INFO] [cargo:uberwar] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Exception merging web.xml [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Exception merging web.xml at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defaul tLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLife cycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Default LifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandl eFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLife cycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja va:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Exception merging web.xml at org.codehaus.cargo.maven2.UberWarMojo.doWebXmlMerge(UberWarMojo.java:21 4) at org.codehaus.cargo.maven2.UberWarMojo.execute(UberWarMojo.java:169) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginM anager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defaul tLifecycleExecutor.java:534) ... 16 more Caused by: java.lang.NullPointerException at org.codehaus.cargo.maven2.UberWarMojo.doWebXmlMerge(UberWarMojo.java:20 8) ... 19 more [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Tue Nov 07 10:55:44 CET 2006 [INFO] Final Memory: 5M/11M [INFO] Here is my merge.xml: uberwar wars wartoto:tutu-web/war wartoto:tutu-testui/war /wars /uberwar -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
Hi Arnaud, The clover plugin is presumably one of the most complex m2 plugin. I had some architecture diagrams to explain how it worked but I've hidden them as the code has changed a bit and I hadn't had the time to update the diagrams. I'll try to find some time today to update them and republish them. Thanks -Vincent -Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: lundi 6 novembre 2006 10:36 To: Maven Users List Subject: Re: We need some explanation ... franz see [EMAIL PROTECTED] writes: Anyway, I'm not sure though if another goal would be bound to the same phase as instrumentInternal. Though I haven't really disected the code to its very core, the architecture provided in [1] seems to indicate that it is forked to its own lifecycle (clover lifecycle). But I haven't trace that part yet where forking happens so I'm not sure if that architectural design is still updated. Yes, there is a custom lifecycle, see [1]. But I do not know what really happens with this lifecycle fork: I must confess I am still confused by this forking stuff. According to the descriptor, the clover plugin runs: generate-sources, test and integration-test phases, with goal instrumentInternal bound to generate-sources. This implies that no other goals from other plugins are run in this phase, so generated sources (eg. from modello plugin) are not covered by clover's instrumentation . If someone with more knowledge than me is lurking around, help appreciated. regards,, [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover- plugin/src/main/resources/META-INF/maven/lifecycle.xml -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
Hi Arnaud, I've added the architecture diagrams. See http://maven.apache.org/plugins/maven-clover-plugin/architecture/architectur e.html I don't know why but some images are not displayed correctly. Here are 2 diagrams explaining 2 use cases: - clover:check - http://maven.apache.org/plugins/maven-clover-plugin/images/clover-check-achi tecture.jpg - clover:report - http://maven.apache.org/plugins/maven-clover-plugin/images/clover-report-arc hitecture.jpg Let me know if something is not clear. Thanks -Vincent -Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: lundi 6 novembre 2006 10:36 To: Maven Users List Subject: Re: We need some explanation ... franz see [EMAIL PROTECTED] writes: Anyway, I'm not sure though if another goal would be bound to the same phase as instrumentInternal. Though I haven't really disected the code to its very core, the architecture provided in [1] seems to indicate that it is forked to its own lifecycle (clover lifecycle). But I haven't trace that part yet where forking happens so I'm not sure if that architectural design is still updated. Yes, there is a custom lifecycle, see [1]. But I do not know what really happens with this lifecycle fork: I must confess I am still confused by this forking stuff. According to the descriptor, the clover plugin runs: generate-sources, test and integration-test phases, with goal instrumentInternal bound to generate-sources. This implies that no other goals from other plugins are run in this phase, so generated sources (eg. from modello plugin) are not covered by clover's instrumentation . If someone with more knowledge than me is lurking around, help appreciated. regards,, [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover- plugin/src/main/resources/META-INF/maven/lifecycle.xml -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Poor man's web.xml merging
Hi Arnaud,
There's also some code to merge Wars in Cargo's code. See
http://cargo.codehaus.org/Merging+WAR+files
I haven't used it myself so I don't know how well it works but it may be
worth a try.
Thanks
-Vincent
-Original Message-
From: Arnaud Bailly [mailto:[EMAIL PROTECTED]
Sent: lundi 6 novembre 2006 23:14
To: users@maven.apache.org
Subject: Poor man's web.xml merging
While trying to use war plugin for overlaying two webapps, I was
bitten by the somewhat obvious problem of how to merge web
descriptors. There does not seem to exist a standard (read mainstream)
way of doing this. All I found searching the ML on nabble was a
reference to some custom development modifying the plugin's standard
behavior and I did not however search the Jira issues.
While certainly not against modifying plugins to suite my needs, I
tried to find a solution less intrusive and I came up with one
simple solution that may (or may not) be worth sharing: Use inclusion
in XML descriptor through internal subset mechanism. This solution is
not really elegant and may become rapidly unwieldy if the number of
webapps to merge is too important or rapidly changing, but it has the
advantage of relying on standard XML mechanisms and not changing maven
or its plugins.
1. Make your web.xml filterable:
You need to add some filtered repository to the war plugin and put
your WEB-INF/web.xml in it. Add the following to the build section:
plugin
artifactIdmaven-war-plugin/artifactId
configuration
webResources
webResource
directory${basedir}/src/main/webapp-filtered/directory
filteringtrue/filtering
includes
include**/*.xml/include
/includes
/webResource
/webResources
/configuration
/plugin
2. Add an entity definition into web.xml:
Each entity definition is a SYSTEM reference whose content is some
variable that will later be filtered:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd; [
!ENTITY external.servlet SYSTEM ${testui.include.servlet}
!ENTITY external.servlet-mapping SYSTEM ${testui.include.mapping}
]
3. Add entities references as needed in the web.xml file.
You need to breakdown the imported descriptor so that DTD validator is
kept happy. You could also set your web application container's XML
parser to some lenient mode so that DTD validation is not enforced
(not tried this).
!-- conditional inclusion of testui descriptor --
external.servlet;
servlet
servlet-nameInit/servlet-name
servlet-classtoto.Init/servlet-class
load-on-startup1/load-on-startup
/servlet
...
!-- conditional inclusion of testui descriptor --
external.servlet-mapping;
servlet-mapping
servlet-namewebapp/servlet-name
url-pattern/my-app/url-pattern
/servlet-mapping
...
4. Add profiles that defines the needed properties to some consistent
value.
In this case, we set a test and a production profile: test profile
import some content while production profile import dummy (empty)
fragments.
profiles
profile
idweb-test/id
properties
testui.include.servletservlet.xml/testui.include.servlet
testui.include.mappingservlet-
mapping.xml/testui.include.mapping
/properties
dependencies
dependency
groupIdtoto/groupId
artifactIdtest-webapp/artifactId
version${version}/version
typewar/type
/dependency
/dependencies
/profile
profile
idweb-prod/id
properties
testui.include.servletdummy-servlet.xml/testui.include.servlet
testui.include.mappingdummy-mapping.xml/testui.include.mapping
/properties
/profile
/profiles
5. In test-webapp project, create servlet.xml and servlet-mapping.xml
fragments from the full descriptor in WEB-INF
6. Then run mvn install with either profile set. With mvn -P web-test,
you end up with a web application containing the imported test-webapp
project's content and with a web.xml like:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd; [
!ENTITY external.servlet SYSTEM servlet.xml
!ENTITY external.servlet-mapping SYSTEM servlet-mapping.xml
]
Note that war overlay mechanism took care of copying servlet.xml and
servlet-mapping.xml from test-webapp.
At load time, the XML parser for the container (tested with Jetty6)
should resolve entities content and include the named files into the
web.xml.
7. enjoy :-)
As already said, I tried all this on one container only and with two
simple web applications. But as this is standard XML mechanism, and
not particularly bleeding edge XML, I do have reasons to
RE: Maven rant
-Original Message- From: Sebastien Brunot [mailto:[EMAIL PROTECTED] Sent: jeudi 2 novembre 2006 10:26 To: Maven Users List Subject: RE: Maven rant I'm just joining, but what about creating a wiki with the entire free maven book content so that the (user) community can update it ? I agree to the fact that you need some predefined structure to ensure effective documentation by users / developers. Adding a snipet of documentation should be a no cost operation, and having a predefined structure may help to achieve this goal. This would be good but it's a choice to be made by Mergere (the publisher of the book). Thanks -Vincent -Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 2:45 PM To: Maven Users List Subject: Re: Maven rant 2 thoughts about what you wrote Vincent: I totally agree on the fact that a few people have to write the core of the documentation before any community effort can be considered. But at some point, a PDF and an errata page is not the best way to create a community effort in order to keep this book up-to-date and more accessible. This leads me to the second point: Maven's wiki doesn't work for the very same reason Cocoon one didn't, for the very same reason I've never seen one good documentation effort based solely on a WIKI: no structure! And that's exactly what your book could be useful as: some sort of a spinal cord on which other content can be aggregated and accumulated over time, and sometimes assimilated on a rewrite. Moreover, I don't believe in Wikis at all because instead of adding some information, it just replaces it, even if it keeps some kind of version tracking behind the scenes. IMHO, Maven documentation should look like that: http://drupal.org/handbooks 2006/10/31, Vincent Massol [EMAIL PROTECTED]: -Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: mardi 31 octobre 2006 14:18 To: Maven Users List Subject: Re: Maven rant I totally agree but I think that the problem is very difficult to solve, especially with all the incredible amount of undeocumented features that Maven has. Moreover, the problem is amplified by the fact that Maven allows the generation of most of the documentation: but if you don't write it, it won't write itself, so you will endup with dead links everywhere. As I see it, the problem in most Open Source projects is that developers do that on their free time, and developers aren't writers: those are two completely different tasks and the second one is not the most enjoyable. And last but not least: Open Source software is highly evolutive: why bother write some documentation for a feature that can be replaced by something more interesting in no-time and without any possible anticipation. The thing is that Maven is not the first Maven project I work with which faces that very issue. I had exactly the same problems a few months ago with Cocoon guys, and my remark is still the same: why do project leaders keep on considering documentation as a static thing. Think of Hibernate or PHP documentation: one base reference book with DYNAMIC comments in which people can share their thoughts and experiences about each feature/chapter, remarks that can be later integrated when the reference is rewritten. The problem is that, whereas development itself is a highly-collaborative and efficient process, nothing is really done so that documentation writing is collaborative enough: no workflow, no direct input, no dynamic comments, etc. Think of it: Better Builds With Maven is the most comprehensive documentation about Maven2. But was it written collaboratively? No. And I'm convinced that if it had been, it would be much higher quality and much more accessible today. Sebastien, I don't believe this is true. This is the same as any open source project. It's not the community that creates an open source project. It's one or two guys (possibly 3 ;-)). Then once there is a strong kernel developed by these few guys then others will join and help. The same is true for documentation. You need one or 2 leaders to first write the core of it. This is what we've done with BBWM. Now I agree that a good idea could be to build on it by opening it up to the community. But don't believe a single instant that the community will write a good quality book by itself. BTW there's already a Maven wiki which is opened to anyone interested. It's been there for more than a year but I wouldn't call the result comprehensive documentation. Thanks -Vincent 2006/10/31, dhoffer [EMAIL PROTECTED]: Jeff, I use maven and I really like it and I don't want this to sound like negative criticism but you are right, the learning curve for maven newbie's is huge and there just
RE: Overview - Ant to Maven
-Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: jeudi 2 novembre 2006 06:46 To: Maven Users List Subject: Re: Overview - Ant to Maven Kevin, I'm not sure there's another way to do a remote deploy. At least, this is how every command-line based deploy tool I've ever used has worked, including deployment tools included with Oracle App Server and other J2EE servers. It might be nice if the tool would instead copy the war file, THEN undeploy, and finally deploy, but it seems like this is just generally not available, at least not from the command line tools. Yes, Wayne is right, there's little Cargo can do here as Cargo is reusing the tools provided by the app servers to do remote deployment. Yesterday I've just implemented redeploy for JBoss 4.x and it was nice to see that the JBoss remote deployer had a redeploy action built in. (However the JBoss remote deployer doesn't copy the artifact to the server so it has to be there but that's another story). What I've suggested to Kevin was to do some research on the Tomcat Manager Application to check if it had a mode for redeploying a WAR or for updating an already deployed WAR. I've noticed there's an update parameter on http://tinyurl.com/ye48z3. I haven't tried it and I don't know what it does. Kevin if you find a way, we'll be happy to modify Cargo's code to use it. Thanks -Vincent On 11/1/06, Kevin Jackson [EMAIL PROTECTED] wrote: for deploying have a look at cargo at: http://cargo.codehaus.org/ I have used the cargo plugin and the tomcat plugin and both of them have a flaw if you are deploying to a remote server (ie one without maven installed on it). When they deploy, they first undeploy your application, then they copy the war file over from your client to the server, then they deploy the new war file (just copied over). This is ok if you have a fast connection between the client machine (running maven) and the server (running tomcat). But if you are doing this over the internet, the time you application is offline can be quite long as you must wait for the whole war file to be copied over while your app isn't available. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB Building
Hi EJ, -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: mercredi 1 novembre 2006 20:56 To: Maven Users List Subject: RE: EJB Building I did - their example mentions building a j2ee project with a single ejb, there's no mention of best practices in regards to multiple ejbs. I wrote that chapter and I didn't put several EJBs because I didn't see what more it would bring to the example as having one or 1000 EJBs is exactly the same AFAICS. If you think there's a difference please let me know or why you think it makes a difference. Thanks -Vincent -Original Message- From: Alexander Sack [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:41 PM To: Maven Users List Subject: Re: EJB Building Look at the Better Builds with Maven 2 book: http://www.mergere.com/m2book_download.jsp This has a whole chapter dedicated to Java EE projects with examples (downloadable from that website). -aps On 11/1/06, EJ Ciramella [EMAIL PROTECTED] wrote: What I'm wondering is, if currently I have 6 lines of ant code that (as per the standard ejb task in ant) recursively finds all the deployment descriptors and builds the ejbs into a specified directory. These ejbs aren't stand alone projects either (as you mention below). How does this work with maven 2? Is there an example of building a web app project with many ejbs? Will this be one parent with dependencies on 10 - 15 child projects? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:17 PM To: Maven Users List Subject: Re: EJB Building I don't know what exactly you're looking for as a response here, EJ. My organization has a variety of EJBs (and Libs, Wars, etc) all being built by M2 with dependencies across modules etc. Realistically you should just take a day or two and just convert 2 or 3 of your EJB projects to Maven2 to see how it works. The poms should be pretty simple assuming you aren't doing anything terribly complex in your Ant scripts. Wayne On 11/1/06, EJ Ciramella [EMAIL PROTECTED] wrote: Is there some place where I can see how maven 2 expects to build ejbs? In an active project here, we have about 10 - 15 ejbs building via ant. Each ejb is in its own directory. How would something like this work in Maven 2? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven rant
-Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: mardi 31 octobre 2006 14:18 To: Maven Users List Subject: Re: Maven rant I totally agree but I think that the problem is very difficult to solve, especially with all the incredible amount of undeocumented features that Maven has. Moreover, the problem is amplified by the fact that Maven allows the generation of most of the documentation: but if you don't write it, it won't write itself, so you will endup with dead links everywhere. As I see it, the problem in most Open Source projects is that developers do that on their free time, and developers aren't writers: those are two completely different tasks and the second one is not the most enjoyable. And last but not least: Open Source software is highly evolutive: why bother write some documentation for a feature that can be replaced by something more interesting in no-time and without any possible anticipation. The thing is that Maven is not the first Maven project I work with which faces that very issue. I had exactly the same problems a few months ago with Cocoon guys, and my remark is still the same: why do project leaders keep on considering documentation as a static thing. Think of Hibernate or PHP documentation: one base reference book with DYNAMIC comments in which people can share their thoughts and experiences about each feature/chapter, remarks that can be later integrated when the reference is rewritten. The problem is that, whereas development itself is a highly-collaborative and efficient process, nothing is really done so that documentation writing is collaborative enough: no workflow, no direct input, no dynamic comments, etc. Think of it: Better Builds With Maven is the most comprehensive documentation about Maven2. But was it written collaboratively? No. And I'm convinced that if it had been, it would be much higher quality and much more accessible today. Sebastien, I don't believe this is true. This is the same as any open source project. It's not the community that creates an open source project. It's one or two guys (possibly 3 ;-)). Then once there is a strong kernel developed by these few guys then others will join and help. The same is true for documentation. You need one or 2 leaders to first write the core of it. This is what we've done with BBWM. Now I agree that a good idea could be to build on it by opening it up to the community. But don't believe a single instant that the community will write a good quality book by itself. BTW there's already a Maven wiki which is opened to anyone interested. It's been there for more than a year but I wouldn't call the result comprehensive documentation. Thanks -Vincent 2006/10/31, dhoffer [EMAIL PROTECTED]: Jeff, I use maven and I really like it and I don't want this to sound like negative criticism but you are right, the learning curve for maven newbie's is huge and there just isn't much good docs available. I have wound up getting bits of pieces of info from here and there...it just takes so long. It would be great if some maven gurus could solve this problem and make maven more accessible. Jeff Mutonho wrote: Is maven in the process of unintentionally killing itself due to poor support and documentation?I may be wrong but I strongly feel that the poor support and documentation is hampering adoption of an otherwise brilliant tool.It always seems like the participation of plugin developers in answering questions from mere users like myself is non-existent.Then lets not forget the poor documentation.The BB book was an excellent idea ,but sometimes it just does not address problems users face on the setup battle field and the configuration trenches we're all familiar with.I'll give an example that relates to my experience.I posted questions relating to problems with the Maven Wagon plugin and in the process also thought it wise to see what the documents say.That led me to http://maven.apache.org/wagon/ and clicking on the Getting Started link I ended up at the URL http://maven.apache.org/wagon/guides/getting-started/index.html , and almost every link there leads to a : = Page Not Found Sorry, the page you requested was not found. This may because: * The page has moved, was outdated, or has not been created yet * You typed the address incorrectly * You following a link from another site that pointed to this page. We have recently reorganised our site, so please try looking in the navigation on the left for the item you are looking for on Maven 1.x or the Maven project. For information about Maven 2.0 or Continuum, please visit their sub sites, available from the links in the top right of the page. There is no need to report this broken link to the Maven team, as
RE: project.build.finalName incorrect in Clover forked lifecycle
Hi Chris,
This looks like a bug in the Clover plugin. Could you please create a jira
issue and I'll look into it?
Thanks
-Vincent
-Original Message-
From: Chris Tucker [mailto:[EMAIL PROTECTED]
Sent: mardi 24 octobre 2006 00:57
To: users@maven.apache.org
Subject: project.build.finalName incorrect in Clover forked lifecycle
Hi all,
I'm having some problems with the maven-clover-plugin and generating
resources (in the generate-resources phase) into the appropriate
target directory. The clover plugin forks a lifecycle and modifies
the build finalName to include the classifier -clover. I generate
a web.xml file (for a war, using xdoclet) using the webdoclet
configuration:
webdoclet destDir=${project.build.directory}/$
{project.build.finalName}/WEB-INF
...
/webdoclet
This configuration is in a custom execution for the xdoclet plugin,
running in the generate-resources phase. It simply states to
generate some output in the destDir location (the particular output
isn't really important).
When the forked lifecycle executes, the project.build.finalName
property is not reflecting the forked lifecycle's value (i.e. it does
not include the -clover classifier). This causes the build to fail,
as the appropriate configuration files are not written for the war
plugin to package up a war.
This problem can also easily be seen by using the maven clover plugin
(to fork a lifecycle) and binding an ant-run task to the generate-
resources phase that simply echoes out the appropriate properties:
execution
idnormal/id
phasegenerate-resources/phase
configuration
tasks
echo message=${project.build.finalName} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
This will print out the same finalName in the initial and forked
lifecycles, even though clover explicitly changes the finalName to
include the classifier.
My question is: am I doing something wrong, or does this look like a
bug in maven? I'm on the latest stable release of maven (2.0.4),
using maven-clover-plugin 2.3 and maven-war-plugin 2.0.1.
One additional piece of interesting (though maybe not relevant)
information is that help:effective-pom shows the interpolated value
of the variable ${project.build.finalName}, while it leaves other
variables (like ${project.build.directory}) in the uninterpreted
form. Is there a reason for this, and if so is it possible that
finalName has been erroneously marked somewhere as constant between
lifecycles?
Cheers,
Chris Tucker
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] maven-cargo-plugin, no longer supported?
-Original Message- From: CodingPlayer [mailto:[EMAIL PROTECTED] Sent: mardi 24 octobre 2006 11:44 To: users@maven.apache.org Subject: [M2] maven-cargo-plugin, no longer supported? Hi, I lately started with my first webapp using Maven2. And i heard that the maven-cargo-plugin would work best, but the website seems to be down: http://cargo.codehaus.org/Maven2+plugin has the plugin moved? Or is it no longer supported? It is definitely supported and working :-) Maybe the site was down temporarily for a maintenance operation at codehaus. It's up again. -Vincent Cargo committer PS: There's a cargo mailing list if you have any further question about Cargo. Which other plugins work good for developing webapps under Maven2? - maven-tomcat-plugin - maven-jetty6-plugin thx 4 help R.C. -- View this message in context: http://www.nabble.com/-M2--maven-cargo- plugin%2C-no-longer-supported--tf2500251.html#a6969876 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 1.1 RC1 SNAPSHOT needs testers
Hi Arnaud, -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: lundi 16 octobre 2006 09:34 To: users@maven.apache.org Subject: Re: Maven 1.1 RC1 SNAPSHOT needs testers I hate these errors ! ;-) We'll add a note to ask to the users to manually remove the cache before the upgrade. Another option is to clean the cache by default upon installation. One simple way of doing it would be to add a marker file named after the version. If there's no file with the current version then maven would clean the cache when it runs and create such a marker file. -Vincent Dion Gillard-2 wrote: Looks like a bad cache/install. I reinstalled, removing the cache and maven directory in the repo and this error went away. On 10/16/06, Dion Gillard [EMAIL PROTECTED] wrote: Doesn't work for me. I get a stacktrace on starting: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT Directory C:\Documents and Settings\Dion Gillard\.maven\cache does not exist. At tempting to create. Plugin cache will be regenerated org.apache.maven.project.Model: method setModelEncoding(Ljava/lang/String;)V not found Exception stack traces : java.lang.NoSuchMethodError: org.apache.maven.project.Model: method setModelEnco ding(Ljava/lang/String;)V not found at org.apache.maven.project.io.dom4j.MavenDom4jReader.parseModel(MavenDo m4jReader.java:1263) at org.apache.maven.project.io.dom4j.MavenDom4jReader.read(MavenDom4jRea der.java:2617) at org.apache.maven.project.io.dom4j.MavenDom4jReader.read(MavenDom4jRea der.java:2628) at org.apache.maven.project.Project.init(Project.java:151) at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:194) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:123) at org.apache.maven.plugin.JellyScriptHousing.getProject(JellyScriptHous ing.java:109) at org.apache.maven.plugin.PluginManager.createPluginHousing(PluginManag er.java:349) at org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManag er.java:240) at org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:3 11) at org.apache.maven.MavenSession.initializePluginManager(MavenSession.ja va:205) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:543) at org.apache.maven.cli.App.main(App.java:1411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:41) at java.lang.reflect.Method.invoke(Method.java:386) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) On 10/10/06, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi everybody, We just deployed a new SNAPSHOT of maven 1.1 RC1 [1]. This version incorporates 2 important changes and we would like to have your feedback : - MAVEN-1755 : We fixed the last main backward incompability with maven 1.0.x, this new version supports XML entities in the POM. - MAVEN-1789 : The default repository is now http://repo1.maven.org/maven/ ( These two issues aren't yet closed because we have to update the documentation and we are waiting for your feedback ;-) ) Be careful, that to use this snapshot version, you'll certainly have to define the following set of remote repositories to download dependencies. maven.repo.remote = http://repo1.maven.org/maven,http://people.apache.org/repo/m1- snapshot-repository/ These version includes severals plugins [4] updated since the beta 3, and particularly the fix for MPARTIFACT-71 to avoid the error about the rejected key of the host if you use the scp or the sftp protocols to deploy your artifacts. The more feedbacks we'll have, the more stable will be the RC1 !! Thanks for your help... Cheers, The maven team. [1] http://people.apache.org/repo/m1-snapshot- repository/maven/distributions/20061009/ [2] http://jira.codehaus.org/browse/MAVEN-1755 [3] http://jira.codehaus.org/browse/MAVEN-1789 [4] http://jira.codehaus.org/browse/MAVEN-1769 -- http://www.multitask.com.au/people/dion/ Rule of Acquisition #91: Hear all, trust nothing. -- http://www.multitask.com.au/people/dion/ Rule of Acquisition #91: Hear all, trust nothing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
RE: Maven 1.1 RC1 SNAPSHOT needs testers
-Original Message- From: Tomasz Pik [mailto:[EMAIL PROTECTED] Sent: lundi 16 octobre 2006 15:17 To: Maven Users List Subject: Re: Maven 1.1 RC1 SNAPSHOT needs testers On 10/16/06, Vincent Massol [EMAIL PROTECTED] wrote: Another option is to clean the cache by default upon installation. One simple way of doing it would be to add a marker file named after the version. If there's no file with the current version then maven would clean the cache when it runs and create such a marker file. This will be very helpful, but should 'clear' only plugins provided by maven distro so users do not have to reinstall 3-rd party plugins. Thomas, it wouldn't clear any plugin at all. Only the cache would be removed and would get rebuilt automatically from the installed plugins. -Vincent ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Demandez à ceux qui savent sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mvn -N install not working for daytrader
Hi Satish, -Original Message- From: Satish Gupta [mailto:[EMAIL PROTECTED] Sent: vendredi 13 octobre 2006 07:12 To: Maven Users List Subject: Re: mvn -N install not working for daytrader Thanks for your reply! Daytrader is the example being dealt with in the book Better Builds with Maven. I am trying to learn how to be able to work with J2EE projects. The book doesn't explicitly say to install a top-level pom.xml. I made a guess and did copy a pom.xml from another part of the book and tha part seem to have worked. Now I am working on the ejb module under daytrader directoy. So I copied a pom.xml from tha section to ejb directory and ran mvn install. Now I am getting the following error: Cannot find parent: org.apache.geronimo.samples.daytrader:daytrader for project: null:daytrader-ejb:ejb:null You don't have to copy, modify or move any file at all of course! I guess the error is simply you're not in the right directory when you type your mvn command. Please double check the book as I remember mentioning the location where you have to type the commands. If you don't succeed plese let me know exactly what page of the book you're referring to. How do people learn Maven? It seems to be popular but the documentation seems very hard to understand! Do you have any suggestions? That's why there's the book... It's supposed to be easy to follow! :-) Thanks -Vincent On 10/12/06, pjungwir [EMAIL PROTECTED] wrote: Hi Satish, Maven expects to find a pom.xml in the current directory. That message means there isn't one there. I don't know what daytrader is. Are you trying to build it from source? Paul Satish Gupta wrote: I am just starting to learn Maven. I am trying to follow the instrucations in Better Builds with Maven but get the following message right off the bat: It requires a project with an existing pom.xml , but the build is not using one. I am using maven2.0.4 on Windows XP. I'd appreciate any help. Thanks -- View this message in context: http://www.nabble.com/mvn--N-install-not-working-for-daytrader- tf2434911.html#a6789679 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Demandez à ceux qui savent sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover Plugin doesn't generate XML report
Hi, -Original Message- From: Gisbert Amm [mailto:[EMAIL PROTECTED] Sent: mercredi 11 octobre 2006 12:18 To: Maven Users List Subject: Clover Plugin doesn't generate XML report I've set configuration generateXmltrue/generateXml /configuration as described on http://maven.apache.org/plugins/maven-clover-plugin/howto.html, but the plugin doesn't seem to produce the XML report. As the doc says there's no report generated, only an XML file which you can link to your web site. See http://tinyurl.com/h5rgu More specifically it says: Note that only the HTML report gets a link in the Project Reports section in generated menu on the site. If you want to link the PDF or XML reports you'll need to do that by modifying your site.xml. For example: [...] Did I miss something? Which file is the XML report supposed to be generated to? There should be a site/clover/clover.xml file generated. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover Plugin doesn't generate XML report
-Original Message- From: Gisbert Amm [mailto:[EMAIL PROTECTED] Sent: mercredi 11 octobre 2006 15:04 To: Maven Users List Subject: Re: Clover Plugin doesn't generate XML report Vincent Massol wrote: I've set configuration generateXmltrue/generateXml /configuration as described on http://maven.apache.org/plugins/maven-clover-plugin/howto.html, but the plugin doesn't seem to produce the XML report. As the doc says there's no report generated, only an XML file which you can link to your web site. See http://tinyurl.com/h5rgu Saying XML report I simply meant XML file. BTW: Is there a certain reason for the duplicate information on this both sites?: http://maven.apache.org/plugins/maven-clover-plugin/howto.html http://maven.apache.org/plugins/maven-clover-plugin/usage.html Hehe... This is because howto doesn't exist anymore but the site deploy plugin doesn't remove old files... We'll need to manually log on the machine and clean the files and then do a redeploy. Thanks for pointing this. Did I miss something? Which file is the XML report supposed to be generated to? There should be a site/clover/clover.xml file generated. It isn't, that's why I ask. Ok sorry. I misunderstood. I thought you meant XML report when you only meant that there's no XML file... :-) What could be the reason for that? Hmmm... Very strange. What version of the clover plugin are you using? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover Plugin doesn't generate XML report
-Original Message- From: Gisbert Amm [mailto:[EMAIL PROTECTED] Sent: mercredi 11 octobre 2006 16:47 To: Maven Users List Subject: Re: Clover Plugin doesn't generate XML report Vincent Massol wrote: There should be a site/clover/clover.xml file generated. It isn't, that's why I ask. Ok sorry. I misunderstood. I thought you meant XML report when you only meant that there's no XML file... :-) What could be the reason for that? Hmmm... Very strange. What version of the clover plugin are you using? The latest release, 2.3. Figured it out!!! My mistake!!! In my pom.xml, there are two plugin sections for the Clover plugin - one in build to configure the history dir and one in reporting for the reports. I simply added historyDir/tmp/cloverhistory/historyDir to the plugin section within build, but it has to be in the one within reporting! Sorry for bothering you. However, those endless XML configuration files are a real pain. Cool. Glad you found the problem. Let me know if you have suggestions to improve the Clover plugin. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Clover Plugin 2.3 for Maven 2 Released
The Maven team is pleased to announce the release of the Maven Clover Plugin, version 2.3 http://maven.apache.org/plugins/maven-clover-plugin/ You can run mvn -U to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clover-plugin/artifactId version2.3/version /plugin Changes: http://tinyurl.com/mldng Release Notes - Maven 2.x Clover Plugin - Version 2.3 ** Bug * [MCLOVER-51] - Clover plugin should use the original dependency if it's newer than the clovered one ** Improvement * [MCLOVER-50] - Test failure during Site goal should not stop the Clover build * [MCLOVER-55] - Upgrade to Clover 1.3.13 ** New Feature * [MCLOVER-48] - Add support for block contexts * [MCLOVER-52] - Support for multiple source code folders ** Task * [MCLOVER-47] - Align plugin documentation with Maven standards * [MCLOVER-56] - Add documentation about the clover:log goal * [MCLOVER-57] - Automate integration tests Note that it's possible that it's going to take some time for the Clover plugin JAR to make its way to the Maven remote repositories. Please be patient. Have fun! -The Maven team ___ Découvrez un nouveau moyen de poser toutes vos questions quel que soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [mvn] clover-plugin documentation is very annoying
-Original Message- From: fuvo [mailto:[EMAIL PROTECTED] Sent: jeudi 5 octobre 2006 19:10 To: users@maven.apache.org Subject: RE: [mvn] clover-plugin documentation is very annoying Hi Vincent, Which version of the plugin are you using? Like in the examples I didn't set a special version. Now, I just tried it with setting version to 2.2 and it works as you said it would. Which version is used when no version is set? My understanding is that Maven will always use the latest released version if you don't have the plugin installed locally (this is BTW the information in http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clover-plugin/m aven-metadata.xml). The only thing I could think of is that you had installed and used the m2 Clover plugin in the past (and older version of it) and that you have not asked Maven2 to update to the latest version (mvn -cpu). In the past I remember Maven2 was prompting you whenever it was finding a new version of a plugin. I haven't seen this behavior for a while so I guess it's been disabled by default. In any case it's a good idea to specify the version of the plugin you wish to use. Note that you can use ranges to specify, for example, that you want to use version 2.2 or greater of the Clover plugin (I don't have the syntax in my head but something like version[2.2,)/version). Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quel que soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [mvn] clover-plugin documentation is very annoying
Hi Volker,
-Original Message-
From: fuvo [mailto:[EMAIL PROTECTED]
Sent: jeudi 5 octobre 2006 17:00
To: users@maven.apache.org
Subject: [mvn] clover-plugin documentation is very annoying
Hello,
I just try to find out if mvn now meets our requirements (availibilty of
the
reports). The last 2 hours I tried to get the maven-clover-plugin to work,
but wherever I placed my clover-license I got the message, that it has
already expired.
I searched the ng, read the documentation and did everything as it has
been
described in the docs. After a few hours I found out (by reading the code)
that I have to use
licenseFile.../licenseFile
Both the documentation and code are correct AFAIK. The correct way is to use
licenseLocation as licenseFile has been deprecated (see
http://maven.apache.org/plugins/maven-clover-plugin/instrument-mojo.html
which mentions the deprecation as of Clover plugin v2.1).
The web site is for the latest version of the plugin (currently v2.2).
instead of
licenseLocation${basedir}/src/test/clover/myclover.license/licenseLocat
ion
(from the docs)
THAT is really annoying! Wrong documentation is by far more useless than
no
documentation.
Then I guess you won't like the Clover plugin compared to lots of other
plugins as it has lots of documentation and thus has a higher risk than
other plugin to have errors in it :-) You'll love all the other plugins
with no documentation though as they have no documentation errors... :-)
When a documentation error is found the correct approach is to create a JIRA
issue for the project and mention it there so that it can be fixed.
Maybe it would help to use a specific version of the maven-clover-plugin
in
the examples.
This something that we do badly indeed:
1) The web site SHOULD display the version of the plugin it is
documentation. This is a regression from Maven 1.x where we had this.
2) The web site should propose documentation for the different releases of
the said plugin so that someone who wants to read the doc for v2.1 of the
Clover plugin can.
Maybe this post can save someones time
Actually it'll make them loose lots of time as what you've mentioned is not
correct and you'll confuse them now and for eternity (as it'll be indexed by
google). Too bad you've now documented it because bad documentation is worse
than no documentation :-)
All that said, it's possible that there's a bug and that the licenseLocation
doesn't work with v2.2 of the plugin. If that's true please raise it as a
bug in JIRA but in any case it won't be a documentation bug as the
licenseLocation is the defined way to do it...
Sorry for this post but this has really upset me :(
I can see that... :-)
Thanks
-Vincent
___
Découvrez un nouveau moyen de poser toutes vos questions quel que soit le sujet
!
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos
expériences.
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [mvn] clover-plugin documentation is very annoying
-Original Message- From: fuvo [mailto:[EMAIL PROTECTED] Sent: jeudi 5 octobre 2006 17:28 To: users@maven.apache.org Subject: RE: [mvn] clover-plugin documentation is very annoying Hi Vincent, sorry, sometimes its better to sleep over something ;-) - sorry for that post. Don't worry! :-) [snip] All that said, it's possible that there's a bug and that the licenseLocation doesn't work with v2.2 of the plugin. If that's true please raise it as a bug in JIRA but in any case it won't be a documentation bug as the licenseLocation is the defined way to do it... I'm not sure - I think it's not only me using the clover plugin. During searching the ng i wondered if I'm the only one with this problem. I try it later again. Which version of the plugin are you using? Thanks -Vincent ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover fails during compile, but project compiles normally
-Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: mardi 26 septembre 2006 20:43 To: Maven Users List Subject: Re: Clover fails during compile, but project compiles normally Vincent Massol wrote: Hi Martin, -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: lundi 25 septembre 2006 20:34 To: Maven Users List Subject: Re: Clover fails during compile, but project compiles normally Don't install and clover at the same time.. I think it should work fine... Any bad experience? :-) The clover plugin is pretty solid :) Except some weird behaviour with instrumentation jars ending up in the local repository :) (Cobertura has this problem too I think) If you have an issue with instrumented jars let me know and I'll have a look. There was an issue with the plugin not using the latest of either the non-instrumented jar or the instrumented one but I've fixed it in SVN some time ago. Which reminds me that I should do a release soon. Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover fails during compile, but project compiles normally
Hi Michael, This is a known issue that I've fixed in v2.3 of the Clover plugin (see http://jira.codehaus.org/browse/MCLOVER-51). Thanks -Vincent -Original Message- From: Michael Waluk [mailto:[EMAIL PROTECTED] Sent: lundi 25 septembre 2006 17:36 To: users@maven.apache.org Subject: Re: Clover fails during compile, but project compiles normally In case anyone searches for something similar and finds this... I don't understand it, but here is how I fixed this: In my local repository I found that next to oba-standalone-1.0-SNAPSHOT.jarwas an older file oba-standalone-1.0-SNAPSHOT-clover.jar. Once I deleted that it ran fine. I guess clover must have seen that old version and didn't create the new snapshot to use as a dependency. Hope that helps someone out there. - Michael On 9/25/06, Michael Waluk [EMAIL PROTECTED] wrote: Hi, My Clover reports worked fine before I renamed some sub-modules. Now during compilation for Clover it can't find the other sub-module that this project depends upon. The normal compile and install works fine as the log snippet shows, but when Clover compiles its version it can't see the dependency. Can anyone guess why that might happen - why Clover doesn't see a dependency but normal compile does? Thanks for any help, Michael Here is where it goes bad [INFO] [install:install] [INFO] Installing C:\views\mw_oba_prj_lptp\oba\standalone\target\oba- standalone-1.0-SNAPSHOT.jar to C:\Documents and Settings\michael.waluk\.m2\repository\com\workscape\oba\oba- standalone\1.0-SNAPSHOT \oba-standalone-1.0-SNAPSHOT.jar [INFO] Installing C:\views\mw_oba_prj_lptp\oba\standalone\target\oba- standalone-1.0-SNAPSHOT-tests.j ar to C:\Documents and Settings\michael.waluk\.m2\repository\com\workscape\oba\oba- standalone\1.0-SN APSHOT\oba-standalone-1.0-SNAPSHOT-tests.jar [INFO] Preparing clover:instrument [WARNING] Removing: instrument from forked lifecycle, to prevent recursive invocation. [INFO] [clover:instrumentInternal] Clover Version 1.3.12, built on February 08 2006 loaded from: C:\Documents and Settings\michael.waluk\.m2\repository\com\cenqua\clover\clover\1.3.12\ clover-1.3.12.jar Server License registered to Workscape No coverage database 'C:\views\mw_oba_prj_lptp\oba\standalone\target/clover/clover.db' found. Creati ng a fresh one. Processing files at 1.5 source level. Instrumented 78 source files. [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 78 source files to C:\views\mw_oba_prj_lptp\oba\standalone\target\clover\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\views\mw_oba_prj_lptp\oba\standalone\target\clover\src\com\workscape\on eforce\apps\builder\Scenar ioFactory.java:[19,38] package com.workscape.oneforce.builder does not exist ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover fails during compile, but project compiles normally
Hi Martin, -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: lundi 25 septembre 2006 20:34 To: Maven Users List Subject: Re: Clover fails during compile, but project compiles normally Don't install and clover at the same time.. I think it should work fine... Any bad experience? :-) Thanks -Vincent Michael Waluk wrote: In case anyone searches for something similar and finds this... I don't understand it, but here is how I fixed this: In my local repository I found that next to oba-standalone-1.0-SNAPSHOT.jarwas an older file oba-standalone-1.0-SNAPSHOT-clover.jar. Once I deleted that it ran fine. I guess clover must have seen that old version and didn't create the new snapshot to use as a dependency. Hope that helps someone out there. - Michael On 9/25/06, Michael Waluk [EMAIL PROTECTED] wrote: Hi, My Clover reports worked fine before I renamed some sub-modules. Now during compilation for Clover it can't find the other sub-module that this project depends upon. The normal compile and install works fine as the log snippet shows, but when Clover compiles its version it can't see the dependency. Can anyone guess why that might happen - why Clover doesn't see a dependency but normal compile does? Thanks for any help, Michael Here is where it goes bad [INFO] [install:install] [INFO] Installing C:\views\mw_oba_prj_lptp\oba\standalone\target\oba- standalone-1.0-SNAPSHOT.jar to C:\Documents and Settings\michael.waluk\.m2\repository\com\workscape\oba\oba- standalone\1.0-SNAPSHOT \oba-standalone-1.0-SNAPSHOT.jar [INFO] Installing C:\views\mw_oba_prj_lptp\oba\standalone\target\oba- standalone-1.0-SNAPSHOT-tests.j ar to C:\Documents and Settings\michael.waluk\.m2\repository\com\workscape\oba\oba- standalone\1.0-SN APSHOT\oba-standalone-1.0-SNAPSHOT-tests.jar [INFO] Preparing clover:instrument [WARNING] Removing: instrument from forked lifecycle, to prevent recursive invocation. [INFO] [clover:instrumentInternal] Clover Version 1.3.12, built on February 08 2006 loaded from: C:\Documents and Settings\michael.waluk\.m2\repository\com\cenqua\clover\clover\1.3.12\ clover-1.3.12.jar Server License registered to Workscape No coverage database 'C:\views\mw_oba_prj_lptp\oba\standalone\target/clover/clover.db' found. Creati ng a fresh one. Processing files at 1.5 source level. Instrumented 78 source files. [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 78 source files to C:\views\mw_oba_prj_lptp\oba\standalone\target\clover\classes [INFO] --- - [ERROR] BUILD FAILURE [INFO] --- - [INFO] Compilation failure C:\views\mw_oba_prj_lptp\oba\standalone\target\clover\src\com\workscape\on eforce\apps\builder\Scenar ioFactory.java:[19,38] package com.workscape.oneforce.builder does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover + Cargo + Maven2 +Jboss
_ From: Patrick Charbonnier [mailto:[EMAIL PROTECTED] Sent: lundi 25 septembre 2006 18:19 To: [EMAIL PROTECTED] Subject: Clover + Cargo + Maven2 +Jboss Hi, sorry to contact you directly but i didnt find a user mailiing list for maven-clover-plugin It is the Maven list. I'm cc-ing it. Please continue answering on the list (after you subscribe to it). im evaluating Clover for a large J2EE project (EJB3) but I cannot figure out a clean scenario. My test case multiproject/ |-- jar1 | |-- pom.xml | `-- src | |-- main | `-- test |-- jar2 | |-- pom.xml | `-- src | |-- main | `-- test `-- pom.xml jar1 is an EJB3 and contains only entities and can be testes without any deployemnt jar2 contains business bean (i.e. SessionBean) and to be tested the jar2 need to be deployed on a running container . This is done by cargo. The problems is that the dependencie jar1 is deployed without instrumentation (because is fetched by maven and decladere in cargo config as deployable ) and all the calls to jar1 during the integration-test for jar2 are not taken into account during the clover:aggregate phase. Have you some suggestions ? I think you're not using the Clover plugin in the correct manner. In order for the clovered artifacts to be used you need to call a clover plugin goal (like clover:check or clover:clover). If you call the build for jar2 using mvn install for example without it running through the clover plugin then nothing will happen. When run through the clover plugin, it modifies the project artifacts to use the clovered versions. If you simply run mvn clover:clover in multiproject/ it should work fine. Thanks -Vincent
RE: [M2] Announcement plug-in for Maven 2?
Hi Andreas, AFAIK it doesn't exist for m2 yet. Thanks -Vincent -Original Message- From: Andreas Guther [mailto:[EMAIL PROTECTED] Sent: lundi 18 septembre 2006 02:17 To: Maven Users List Subject: [M2] Announcement plug-in for Maven 2? Hi, I am having a hard time finding a Maven 2 version of the Announcement plug-in from Vincent Massol that is available for Maven 1. I looked at http://mojo.codehaus.org/ and http://maven.apache.org/plugins/ and used all my limited Google skills. Maybe I am just blind or maybe it just does not exist yet. Does someone know if there is a Maven 2 version of the Announcement plug-in and if so, where I can find it? Thanks in advance, Andreas ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo deploy on to a remote machine
Hi Prashanth, As it has been suggested, please use the cargo mailing list if you need more information and help. Note that I've also answered to you already on this list... :-( Thanks -Vincent -Original Message- From: Prashanth Krishnamurthy [mailto:[EMAIL PROTECTED] Sent: mercredi 13 septembre 2006 21:09 To: continuum-users@maven.apache.org Subject: Re: Cargo deploy on to a remote machine I did try cargo:undeploy. undeploy works fine. But when I use deploy again, it fails with an error, something like ..Application with that name already exists.. thanks --Prashanth --- Wayne Fay [EMAIL PROTECTED] wrote: Did you try cargo:undeploy? I don't currently use Cargo, but I'd expect that's a valid goal/target. Also, it might be more appropriate to send this question to the Cargo Users email list... Wayne On 9/12/06, Prashanth Krishnamurthy [EMAIL PROTECTED] wrote: I am trying to deploy my application to a running tomcat instance on a different machine. I have tried the following and haven't been successfully. What is the right way to do this? Please suggest. 1.mvn cargo:deploy - This works fine only when the tomcat instance doesn't have my application deployed. 2. mvn cargo:deploy - This fails when run against a tomcat instance which already has my application running or deployed. Failed to deploy [c:\main\app\ui\target\aa.war] Application already exists at path /aa 3. mvn cargo:deployer-redeploy - This goal undeploys and redeploys the application. I guess this is deploying the existing war file without refreshing with the new war file. 4. mvn cargo:deployer-redeploy - This fails when run against a tomcat instance which doesn't have my running or deployed. [INFO] Failed to redeploy [c:\main\app\ui\target\aa.war] FAIL - No context exists for path /aa thanks --Prashanth __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
RE: Cargo deploy on to a remote machine
Hi Prashanth, Please use the Cargo mailing list. What you want is not implemented yet. You need to do undeploy first in your case. Cargo is currently mimicking exactly what you get when you use the Tomcat Managa Application. However we need to do better, see http://jira.codehaus.org/browse/CARGO-403 and http://jira.codehaus.org/browse/CARGO-242. Please continue the discussion on the Cargo mailing lists. Thanks -Vincent -Original Message- From: Prashanth Krishnamurthy [mailto:[EMAIL PROTECTED] Sent: mercredi 13 septembre 2006 03:17 To: continuum-users@maven.apache.org Subject: Cargo deploy on to a remote machine I am trying to deploy my application to a running tomcat instance on a different machine. I have tried the following and haven't been successfully. What is the right way to do this? Please suggest. 1.mvn cargo:deploy - This works fine only when the tomcat instance doesn't have my application deployed. 2. mvn cargo:deploy - This fails when run against a tomcat instance which already has my application running or deployed. Failed to deploy [c:\main\app\ui\target\aa.war] Application already exists at path /aa 3. mvn cargo:deployer-redeploy - This goal undeploys and redeploys the application. I guess this is deploying the existing war file without refreshing with the new war file. 4. mvn cargo:deployer-redeploy - This fails when run against a tomcat instance which doesn't have my running or deployed. [INFO] Failed to redeploy [c:\main\app\ui\target\aa.war] FAIL - No context exists for path /aa thanks --Prashanth __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
RE: Clover and additional target/src directory
-Original Message- From: Ingo Düppe [mailto:[EMAIL PROTECTED] Sent: lundi 4 septembre 2006 15:55 To: Maven Users List Subject: Re: Clover and additional target/src directory Hi Vincent, my intension to clover generated sources is that we also write some unit tests for generated sources. We do this to be sure that the generator works like expected. In particular the andromda 3.2 version is not released yet. So the unit tests helps us to be informed that the generator changed his behaviour. Ok, I've started implementing it. I have decided to add a new configuration parameter to decide whether all source roots should be instrumented or not. By default I've put this parameter to false so that all source roots are not included by default (to keep the current behavior). Thus, in your case you'll need to add the following: includesAllSourceRootstrue/includesAllSourceRoots Thanks -Vincent Vincent Massol schrieb: -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: vendredi 1 septembre 2006 11:11 To: 'Maven Users List' Cc: '[EMAIL PROTECTED]' Subject: RE: Clover and additional target/src directory Hi Ingo, -Original Message- From: Ingo Düppe [mailto:[EMAIL PROTECTED] Sent: vendredi 1 septembre 2006 01:22 To: Maven Users List Subject: Clover and additional target/src directory Hi, I use AndroMDA to generate my sources under /target/src and we uses clover to for code coverage. But coverage does not recognize the generated sources under /target/src. How can I add my target/src folder to clover? I've checked the clover plugin source code and indeed other source roots are not added. There's even a comment saying that it's not added voluntarily. Now thinking about it's probably warranted to add all source roots. There may be cases when some source roots should not be added but let's wait till they materialize. To summarize: I agree to modify the clover plugin to add all source roots by default. Could you please create a jira issue for this and I'll work on it? Actually I need more information from you. I'm still unsure whether we should do this or not and I need to understand why you want generated AndroMDA sources to get clovered? I'm not sure why anyone would want generated sources to be clovered? Mind you, I'm not against it; I'd just like a valid use case for this. Thanks -Vincent p2.vert.ukl.yahoo.com uncompressed Mon Sep 4 07:27:01 GMT 2006 __ _ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover failing in maven2/Continuum1.0.3 build
Hi Meghan, -Original Message- From: mcp [mailto:[EMAIL PROTECTED] Sent: mercredi 2 août 2006 14:57 To: continuum-users@maven.apache.org Subject: Clover failing in maven2/Continuum1.0.3 build HI, I'm attempting to run Clover coverage analysis on serveral maven 2.0 projects with various subprojects and modules. I'm using Continuum to automatically build / test and generate reports on all these projects (~20) but on two it fails. The tests build and pass successfully using surefire, but then clover instruments them and they all fail. Not a continuum problem you might think, but unfortunately it all builds happily using just maven and clover outside of continuum. It's only in continuum that it fails. Could you please send us the log files for the failing tests (they're in the surefire-reports directory)? [snip] Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
RE: Clover and additional target/src directory
-Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: vendredi 1 septembre 2006 11:11 To: 'Maven Users List' Cc: '[EMAIL PROTECTED]' Subject: RE: Clover and additional target/src directory Hi Ingo, -Original Message- From: Ingo Düppe [mailto:[EMAIL PROTECTED] Sent: vendredi 1 septembre 2006 01:22 To: Maven Users List Subject: Clover and additional target/src directory Hi, I use AndroMDA to generate my sources under /target/src and we uses clover to for code coverage. But coverage does not recognize the generated sources under /target/src. How can I add my target/src folder to clover? I've checked the clover plugin source code and indeed other source roots are not added. There's even a comment saying that it's not added voluntarily. Now thinking about it's probably warranted to add all source roots. There may be cases when some source roots should not be added but let's wait till they materialize. To summarize: I agree to modify the clover plugin to add all source roots by default. Could you please create a jira issue for this and I'll work on it? Actually I need more information from you. I'm still unsure whether we should do this or not and I need to understand why you want generated AndroMDA sources to get clovered? I'm not sure why anyone would want generated sources to be clovered? Mind you, I'm not against it; I'd just like a valid use case for this. Thanks -Vincent p2.vert.ukl.yahoo.com uncompressed Mon Sep 4 07:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover and additional target/src directory
Hi Ingo, -Original Message- From: Ingo Düppe [mailto:[EMAIL PROTECTED] Sent: vendredi 1 septembre 2006 01:22 To: Maven Users List Subject: Clover and additional target/src directory Hi, I use AndroMDA to generate my sources under /target/src and we uses clover to for code coverage. But coverage does not recognize the generated sources under /target/src. How can I add my target/src folder to clover? I've checked the clover plugin source code and indeed other source roots are not added. There's even a comment saying that it's not added voluntarily. Now thinking about it's probably warranted to add all source roots. There may be cases when some source roots should not be added but let's wait till they materialize. To summarize: I agree to modify the clover plugin to add all source roots by default. Could you please create a jira issue for this and I'll work on it? Thanks -Vincent p4.vert.ukl.yahoo.com uncompressed Fri Sep 1 08:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Integration Testing
-Original Message- From: Heck, Joe [mailto:[EMAIL PROTECTED] Sent: mercredi 30 août 2006 22:54 To: Maven Users List Subject: RE: Integration Testing We have several different mechanisms running - but most of them are honestly manual. The automated solution that one of our teams have come up and and stuck with is the following: 1) set up a multi-module maven2 project, with one of those modules being a functional test suite, another the WAR that we're pushing and banging on. 2) using cargo, we deploy the WAR produced to an instance of Tomcat running on an available and preset QA machine. 3) We invoke the functional tests (primarily httpunit stuff) locally. The how to for the separate functional test module setup was on this earlier - the big pieces to note being that the functional test module is set with POM packaging, and then plugins manually bound to the various steps (in this case, the maven-surefire-plugin bound to the integration-test phase and the cargo plugin bound to the pre-integration-test phase) We've additionally set it up so that functional tests are only included with a specific profile (originally named functional-tests) so that your personal builds will invoke them only when desired. Anything much more complex than this, and I think we'd need to reach out of maven with a custom AntTask bound in there to do setup/teardown kinds of work. Yes and FWIW note that you can invoke Cargo directly from your functional tests, in a Junit's setUp()/tearDown() method from a TestSetup class. See http://cargo.codehaus.org/Functional+testing for an example. -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruel Loehr Sent: Wednesday, August 30, 2006 1:33 PM To: Maven Users List Subject: Integration Testing I'd like to query the community and see how you guys are handling integration testing in real world environments. I've looked through the list and the Better builds book, but didn't like what I saw.. Here is the use case: Use Case A: A user has a project which builds a war. For integration testing the war needs to be deployed in an app server. The process will be to startup the app server, deploy the war, run unit tests, stop the app server. Here is the gotcha. App servers can have many configurations. In this case, we would like to test the functionality of this war on three different app server configurations. Use case A would need to be executed 3 times automatically, each time with a different server configuration. Assuming I already know how to modify the appserver configs, any suggestions on how the repeated execution of this use could be achived in scalable fashion (e.g. if I have 25 server configurations my build file won't be a nightmare to maintain). In ant, it's pretty simple as I can just string together targets until my heart is content. With maven, I feel I am imprisoned by the lifecycle in this case. Ruel Loehr JBoss, a division of Red Hat QA -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/433 - Release Date: 8/30/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] p5.vert.ukl.yahoo.com uncompressed Thu Aug 31 06:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] My tests are launched 3 times !
Hi Benoit, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: mercredi 30 août 2006 16:25 To: users@maven.apache.org Subject: [M2] My tests are launched 3 times ! Hi all, I run a 'mvn clean site install' and my tests are launched 3 times : If you run mvn test:test test:test test:test test:test your tests will be executed 4 times :-) Site and Install are different lifecycles so by running both you're explicitely asking maven to run the tests several times. Maven cannot really guess by itself if the tests have to be re-executed or not. Take for example the Clover plugin. It MUST re-execute the tests because it executes them on clovered sources and not on the original sources. If Maven were to execute the tests only once the clover plugin would report 0% coverage. However it should be possible (but that's a core change) for Maven to know if a plugin goal has already been called within a lifecycle and decide not to re-execute it. That said for it to work it would need the help from plugins who would need to tell Maven whether it should still force the executions. But then the pb is that the plugins do NOT know what goals are executed. They only know about phases. So they would need to say wether plugins bound to such phase should be re-executed or not. All this is relatively messy and I'm pretty sure we'd discover some edge cases... Another related use case is to know whether the tests should be run twice if I run mvn test twice. We could have the surefire plugin by default verify that the test results are newer than any of the source and configuration files and decide not to run the tests again. Of course there would need to be a flag to tell it always rerun the tests. All these ideas can improve fine-tuning of tests but they're going to be compensated by the additional complexity they bring. Users would need to perfectly understand lifecycles and goals bound to them which is probably going to cause some troubles and questions on the mailing list... ;-) All in all, I'd love tests to be executed only once but I have no idea how to make it work from all angles. On for the surefire report plugin, one for the cobertura plugin and one for the install plugin. Although I don't know the cobertura plugin this sounds normal. The clover plugin will also do this. See above. How can i do to have them launched only once ? Only tell Maven to run them once. For example: remove the cobertura plugin usage and run mvn install. They'll run only once ;-) ahahaha -Vincent p2.vert.ukl.yahoo.com uncompressed Thu Aug 31 08:27:00 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Integration Testing
-Original Message- From: Ruel Loehr [mailto:[EMAIL PROTECTED] Sent: jeudi 31 août 2006 16:10 To: Maven Users List Subject: RE: Integration Testing I appreciate the feedback. I think these are all valid workarounds, but have my concerns about scalability and ease of use for users. BTW, I'm not ranting here, just trying to show that use cases exist for which the functionality of M2 might need to improved upon. Our actual testsuite for JBossAS starts and stops different server configurations 15-20 times as well as starting up clusters of servers. From what I can see, to do this the maven way, I would need 15-20 integration projects which would be executed by hand or cruise control or 1 integration project with 15-20 profiles executed in the same fashion as above. Neither one of those solutions provides the same level of functionality as what I can achieve using ant. Another key point I have to deal with is simply the migration and the user experience. Currently they can go into our testsuite and issue: ant tests At which time our entire testsuite will run, performing integration testing for all configurations. I can't take away that functionality. SOto achive this, it sounds like I need to write a plugin which allows many executions, where For each execution a) configure server and start it b) deploy app c) run unit tests d) undeploy app e) stop server Or simply use cargo in your test as shown here: http://cargo.codehaus.org/Functional+testing You can then pass configuration parameters to your tests by using the systemProperties element of the surefire plugin. Then wrap this with a Test Suite to run as many configs as you want. [snip] -Vincent p4.vert.ukl.yahoo.com uncompressed Thu Aug 31 13:27:00 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo and Ant Properties
Hi Matt,
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: jeudi 31 août 2006 22:50
To: Maven Users List
Subject: Cargo and Ant Properties
This might be a Cargo question, but I tried to subscribe to their
mailing list several times w/o success. Must be on of those days...
;-)
I thought you were already subscribed... Codehaus has moved to a new system
since the outage of a few months back. There's now a web interface for doing
everything. See http://xircles.codehaus.org/manage_email
I seem to have successfully integrated Cargo with Canoo WebTest using
Maven 2. I'm doing this as part of AppFuse's move from Ant to Maven
2. My antrun-plugin is configured as follows:
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseintegration-test/phase
configuration
tasks
taskdef
file=src/test/resources/webtestTaskdefs.properties/
mkdir dir=target/webtest-data/
!-- Delete old results file if it exists
--
delete
file=target/webtest-data/web-tests-result.xml/
!-- This is so the default will be
used if no test case is specified --
property name=testcase
value=run-all-tests/
echo level=infoTesting with locale
'${user.language}'/echo
ant
antfile=src/test/data/web-tests.xml inheritRefs=true/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
...
/plugin
The echo from my pom.xml works fine:
[echo] Testing with locale 'en'
But it doesn't seem like this property (${user.language}) is resolved
in the web-tests.xml file that's called.
[INFO] [talledLocalContainer] WARN - ValidatorResources.getForm(448) |
Form 'null' not found for locale '${user.language}'
Is it possible to read Cargo's properties in the Ant file that's
called? For example, it'd be nice if I could make my host, port and
basepath values variables rather than hard-coded.
config host=localhost port=8080 protocol=http
basepath=appfuse-spring-war-2.0-SNAPSHOT
resultpath=target/webtest-data saveresponse=true
resultfile=web-tests-result.xml summary=true
header name=Accept-Language value=${user.language}/
/config
I've attached my pom.xml in case someone has time to critique it.
Why don't you use Cargo's Maven2 plugin
(http://cargo.codehaus.org/Maven2+plugin)? :-)
Thanks
-Vincent
p4.vert.ukl.yahoo.com uncompressed Thu Aug 31 20:27:00 GMT 2006
___
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos
expériences.
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo Goal
Hi Douglas, Actually I don't believe this is a cargo issue. Could you run mvn help:effective-pom? You'll probably see that you've used the wrong artifactId somewhere in a parent POM or in a profile... :-) Thanks -Vincent -Original Message- From: Douglas Ferguson [mailto:[EMAIL PROTECTED] Sent: mercredi 30 août 2006 00:52 To: users Subject: Cargo Goal Cargo was working for me and suddenly it just stopped working and starting giving this error: The plugin 'org.apache.maven.plugins:maven-cargo-plugin' does not exist The thing that is confuse is that is says Org.apache.maven.plugisn maven-cargo-plugin When I have: groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId In my pom file. D- p4.vert.ukl.yahoo.com uncompressed Wed Aug 30 06:27:00 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ad: RE: Tomcat Deploy
-Original Message- From: Douglas Ferguson [mailto:[EMAIL PROTECTED] Sent: mardi 29 août 2006 13:00 To: Maven Users List Subject: RE: Ad: RE: Tomcat Deploy Ah.. Just use this instead of cargo? What's the benefit of Cargo if you can use this directly? What's the benefit of the tomcat plugin if you can use cargo? ;-) More seriously the advantage of cargo is that it supports lots of containers using the same generic Java API, the same m2 plugin, etc. You also get all those integrations (m1, ant, m2, java, IDEs, etc). Note that the m2 plugin is only an extension of Cargo and that the core Cargo is Java API that can be used anywhere (even directly in your functional tests). If there's a feature you'd like to see in cargo please talk to us on the cargo list and open a jira issue for it. Thanks -Vincent PS: I'm very biased of course as I'm one of the committers on cargo :-) - Original Message - From: Stefan Magnus Landrø Sent: Tue, 8/29/2006 1:48am To: Maven Users List Subject: Ad: RE: Tomcat Deploy Hey Douglas, Try this plugin: http://mojo.codehaus.org/tomcat-maven-plugin/ There is a similar one for maven 1 Jeff Jensen [EMAIL PROTECTED] skrev 28.08.2006 22:46:24: Maven 1 or 2? -Original Message- From: Douglas Ferguson [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 3:45 PM To: users Subject: Tomcat Deploy We just made the ant to maven switch and we lost our ability to do file deploy. Which just amounted to copying the files into the context directory. Cargo doesn't appear to support this, does anybody have an elegant solution? I could just write an ant script but I wanted to piggyback based on the contextName which is already defined with our cargo plugin. Is it possible to define a custom goal without writing a plugin? I.E. could I tie an ant run to a custom goal name? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] p5.vert.ukl.yahoo.com uncompressed Tue Aug 29 10:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clover plugin problem
Hi Charlie, Im answering on the maven list as this is the right location where to ask questions. Please use the list in the future. I dont know whats wrong in your case but I know how to find the answer. Please run maven in debug mode (-X) and check the console logs. More specifically look for the string Parameter list being passed to Clover CLI: and check the parameters. Let us know what you find so that we can fix this NPE. Thanks -Vincent _ From: falcon project [mailto:[EMAIL PROTECTED] Sent: vendredi 25 août 2006 21:06 To: [EMAIL PROTECTED] Subject: clover plugin problem Hi, I am trying to get clover maven 2 plgin working but seem to have run into a problem during first off db generation. Here is the snipet of my pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clover-plugin/artifactId configuration jdk1.5/jdk /configuration executions execution phasepre-site/phase goals goalinstrument/goal /goals /execution /executions /plugin .. The I run mvn site and I am getting a error: [INFO] Preparing clover:instrument [WARNING] Removing: instrument from forked lifecycle, to prevent recursive invoc ation. [INFO] [clover:instrumentInternal] Clover Version 1.3.12, built on February 08 2006 loaded from: C:\Documents and Settings\Charlie\.m2\repository\com\cenqua\clover\ clover\1.3.12\clover-1.3.12.jar 30 day Evaluation Version distributed via the Maven Jar Repository. Clover is not free. You have 30 days to evaluate it. After this, please visit ht tp://www.cenqua.com to obtain a licensed version of Clover No coverage database 'D:\coding\eWork\falconCore\trunk\target/clover/clover.db' found. Creating a fresh one. Processing files at 1.5 source level. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at com.cenqua.clover.CloverInstr.a(1.3.12-build-649:100) at com.cenqua.clover.CloverInstr.mainImpl(1.3.12-build-649:65) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.instrumen tSources(CloverInstrumentInternalMojo.java:156) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.execute (C loverInstrumentInternalMojo.java:122) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy cle(DefaultLifecycleExecutor.java:891) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(Def aultLifecycleExecutor.java:734) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:505) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Fri Aug 25 13:35:47 BST 2006 [INFO] Final Memory: 4M/10M [INFO] Not sure what I have done wrong.. and haven't managed to find a similar thread.. Please any advice will be appriciated. Charlie
RE: How to write groovy plugins/mojos?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: vendredi 25 août 2006 09:48 To: Lakshman Srilakshmanan Cc: Maven Users List Subject: RE: How to write groovy plugins/mojos? Yes, but i've encountered some issues on compiling the whole, it using some old groovy distribution. So i'm trying to contact the plugin author, and can anyone told me if the codehaus mojo mailing list is working cause' i've send several emails for registering, ain't got no answers... I think you need to use xircles now (yeah I know it's a pain): http://xircles.codehaus.org/manage_email -Vincent Selon Lakshman Srilakshmanan [EMAIL PROTECTED]: Hi Did you try http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-tools/ Thanks Lakshman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 25 August 2006 12:04 AM To: Maven Users List; Tomasz Pik Cc: Maven Users List Subject: Re: How to write groovy plugins/mojos? Thanks, I've tried to compile all the sources but it seems quite old and doesn't work well. I 've contacted the plugin developper but no answer (maybe holidays:), does anyone know if he still working on it ?? Maybe i can help ... Ben *** Benoit doumas J2EE consultant www.octo.com www.doumas.com *** Selon Tomasz Pik [EMAIL PROTECTED]: On 8/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, I've seeing on the mailing list that it should be possible to write groovy mojos, like to write Ant mojos. But the project : groovy-maven-tools doesn't seem to work ... (http://mojo.codehaus.org/groovy-maven-tools = not found) you may find it here: http://svn.mojo.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/groovy- maven-tools but I'm worry that's all I can help. regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] p4.vert.ukl.yahoo.com uncompressed Fri Aug 25 07:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo Tomcat
-Original Message- From: Ralph Pöllath [mailto:[EMAIL PROTECTED] Sent: jeudi 24 août 2006 11:36 To: Maven Users List Subject: Re: Cargo Tomcat On 24.08.2006, at 00:03, Vincent Massol wrote: Hi Doug, -Original Message- From: Douglas Ferguson [mailto:[EMAIL PROTECTED] Sent: mercredi 23 août 2006 22:44 To: users Subject: Cargo Tomcat Anybody using cargo with tomcat? Im curious about how you deal with quick dev cycle changes where you might want to push 1 file but dont want to do an entire build to do so. Yes this can be done with Cargo and Tomcat. It's not documented yet but you can see a test project that does it here: http://fisheye.codehaus.org/browse/cargo/cargo/trunk/samples/ extensions/mave n2/src/test/projects/testStartInplaceDevelopment In this scenario, will Tomcat pick up the class files from target/ classes/ and jars from my local m2 repository? No it won't. It'll only pick up the modified files in your src/main/webapp dir. Or do I have to use war:inplace (which I'd rather not)? Please use the cargo list for discussing cargo-related stuff. Thanks -Vincent p5.vert.ukl.yahoo.com uncompressed Thu Aug 24 09:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to write groovy plugins/mojos?
Benoit, You could also try posting on the mojo list as it's a mojo project, although I believe most mojo developers will also be on the maven list. -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: jeudi 24 août 2006 16:04 To: Maven Users List; Tomasz Pik Cc: Maven Users List Subject: Re: How to write groovy plugins/mojos? Thanks, I've tried to compile all the sources but it seems quite old and doesn't work well. I 've contacted the plugin developper but no answer (maybe holidays:), does anyone know if he still working on it ?? Maybe i can help ... Ben *** Benoit doumas J2EE consultant www.octo.com www.doumas.com *** Selon Tomasz Pik [EMAIL PROTECTED]: On 8/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, I've seeing on the mailing list that it should be possible to write groovy mojos, like to write Ant mojos. But the project : groovy-maven-tools doesn't seem to work ... (http://mojo.codehaus.org/groovy-maven-tools = not found) you may find it here: http://svn.mojo.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/groovy- maven-tools but I'm worry that's all I can help. regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] p5.vert.ukl.yahoo.com uncompressed Thu Aug 24 13:27:00 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo Tomcat
Hi Doug, -Original Message- From: Douglas Ferguson [mailto:[EMAIL PROTECTED] Sent: mercredi 23 août 2006 22:44 To: users Subject: Cargo Tomcat Anybody using cargo with tomcat? Im curious about how you deal with quick dev cycle changes where you might want to push 1 file but dont want to do an entire build to do so. Yes this can be done with Cargo and Tomcat. It's not documented yet but you can see a test project that does it here: http://fisheye.codehaus.org/browse/cargo/cargo/trunk/samples/extensions/mave n2/src/test/projects/testStartInplaceDevelopment In the future please use the Cargo mailing list for any cargo-related question. BTW we are accepting documentation patches so if you have a good experience using it and you want to document it we'd love that! :-) Thanks -Vincent p5.vert.ukl.yahoo.com uncompressed Wed Aug 23 21:27:00 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven with cargo plugin
Hi Franck, -Original Message- From: HUGOT Franck [mailto:[EMAIL PROTECTED] Sent: mardi 22 août 2006 09:36 To: Maven Users List Subject: Maven with cargo plugin Hello, With cargo plugin, I would like to know if it's possible in only one goal to deploy a war if it does not exist in a container (example tomcat), and redeploy it if it already exists. I try to use deployer-redeploy or deployer-deploy goals, but it throws an error. No this is not currently in the cargo plugin but is a nice to have feature. Please feel free to create a JIRA issue for it (and a patch of course ;-)). Also, please use the Cargo mailing lists for discussing anything related to Cargo. Thanks -Vincent p5.vert.ukl.yahoo.com uncompressed Tue Aug 22 08:27:00 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] surefire and integration tests - discrepancy
Hi Tony, It's not supposed to happen. You need to give us more information so that we can be of any help. Like the error you're getting, your test case, whether there are any environment variables required by your tests, etc. Thanks -Vincent -Original Message- From: Tony Truong [mailto:[EMAIL PROTECTED] Sent: lundi 21 août 2006 09:53 To: users@maven.apache.org Subject: [m2] surefire and integration tests - discrepancy Hi all, I am currently running functional tests with surefire + cargo and IntelliJ IDEA. I have set both to the same container (tomcat5). When the tests are executed, I seem to get failures in surefire + cargo that does not appear on IDEA. Could this be a test environment issue or a bug in surefire (or in cargo)? NOTE: Both are using the same jdk + junit version. Tony. -- View this message in context: http://www.nabble.com/-m2--surefire-and- integration-tests---discrepancy-tf2138839.html#a5902585 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] p5.vert.ukl.yahoo.com uncompressed Mon Aug 21 07:27:01 GMT 2006 ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] surefire and integration tests - discrepancy
From what you're showing the error is coming from your test as the
stacktrace shows an AssertionFailedError which comes from your assert
statement.
You're showing only a small portion of your test case. Do you have a setup()
method or some statics like a suite() method?
Are you sure you're setting the basedir environment variable to the same
location in IDEA as it's set up in Maven2?
-Vincent
-Original Message-
From: Tony Truong [mailto:[EMAIL PROTECTED]
Sent: lundi 21 août 2006 10:15
To: users@maven.apache.org
Subject: RE: [m2] surefire and integration tests - discrepancy
This is the test case:
public void testExportPdfWithPng() throws Exception
{
String confDir = getTestProperty(basedir);
File image;
//if statement included for compatability with maven 2 and IDEA
if (confDir == null)
{
image = new File(src/test/etc/starryNight.png);
} else
{
image = new File(confDir + /src/test/etc/starryNight.png);
}
rpcCreateTestPage(rpcGetAdminToken());
rpcEditPage(rpcGetAdminToken(), TESTSPACE_KEY, TESTPAGE_TITLE,
TESTPAGE_TITLE, ! + image.getName() +!);
viewPage(TESTSPACE_KEY, TESTPAGE_TITLE);
attachFile(image, Vincent van Gogh (1889));
viewPage(TESTSPACE_KEY, TESTPAGE_TITLE);
clickLinkWithText(Info);
clickLinkWithText(PDF);
long imageLength = image.length();
int contentLength = getDialog().getResponse().getContentLength();
assertTrue(PDF should be bigger than included image ( +
imageLength + bytes), but was only + contentLength + bytes,
contentLength imageLength);
}
This is the error im getting:
[ stacktrace ] ---
junit.framework.AssertionFailedError: PDF should be bigger than included
image (616766 bytes), but was only 212647 bytes
This test runs under IDEA with the same container deployed (i.e. Tomcat
5.5.17 jdk1.4 patched). This test case passes under IDEA.
Tony
vmassol wrote:
Hi Tony,
It's not supposed to happen. You need to give us more information so
that
we
can be of any help. Like the error you're getting, your test case,
whether
there are any environment variables required by your tests, etc.
Thanks
-Vincent
-Original Message-
From: Tony Truong [mailto:[EMAIL PROTECTED]
Sent: lundi 21 août 2006 09:53
To: users@maven.apache.org
Subject: [m2] surefire and integration tests - discrepancy
Hi all,
I am currently running functional tests with surefire + cargo and
IntelliJ
IDEA. I have set both to the same container (tomcat5).
When the tests are executed, I seem to get failures in surefire + cargo
that
does not appear on IDEA. Could this be a test environment issue or a
bug
in
surefire (or in cargo)?
NOTE: Both are using the same jdk + junit version.
Tony.
--
View this message in context: http://www.nabble.com/-m2--surefire-and-
integration-tests---discrepancy-tf2138839.html#a5902585
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
p5.vert.ukl.yahoo.com uncompressed Mon Aug 21 07:27:01 GMT 2006
__
_
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le
sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions
et
vos expériences.
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context: http://www.nabble.com/-m2--surefire-and-
integration-tests---discrepancy-tf2138839.html#a5902875
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
p5.vert.ukl.yahoo.com uncompressed Mon Aug 21 08:27:01 GMT 2006
___
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos
expériences.
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cargo deploy jboss datasource-ds.xml file?
Hi James,
You should post to the cargo lists. You'll probably get more answers there.
If you post there please be sure to tell us if you're really talking about
an oracle-ds.xml file or some jboss ds file.
Thanks
-Vincent
-Original Message-
From: James Richards [mailto:[EMAIL PROTECTED]
Sent: mercredi 9 août 2006 00:46
To: users@maven.apache.org
Subject: cargo deploy jboss datasource-ds.xml file?
Hello all,
I'm using the Cargo plugin to deploy to a JBoss 4.x instance:
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
configuration
container
containerIdjboss4x/containerId
!-- JBOSS log --
output${project.build.directory}/jboss4x.log/output
!-- CARGO log --
log${project.build.directory}/cargo.log/log
zipUrlInstaller
urlhttp://umn.dl.sourceforge.net/sourceforge/jboss/jboss-
4.0.4.GA.zip/url
installDir${installDir}/installDir
/zipUrlInstaller
/container
/configura
I have an oracle-ds.xml file which I would like to be deployed so that the
datasources are configured prior to my web application starting. I tried
installing the file directly into the ${installDir}/server/default/deploy
directory as well as the ${installDir}/server\default\deploy\jbossweb-
tomcat55.sar directories but neither seem to pick up the file. The
problem is that cargo is deploying to the target directory. Is there any
way to tell cargo to include oracle-ds.xml to the
${build.output.directory}\jboss4x\deploy directory so that it will deploy
the datasources?
Thanks again for your time,
James
___
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos
expériences.
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo-plugin 0.3-SNAPSHOT problem?
Hi Michael,
Please post to the cargo lists. When you post there please be sure to post
your effective pom (mvn help:effective-pom). Also you shouldn't have both
start and deploy goals as start does static deployment. Check the online
docs. Let's continue this discussion on the cargo list.
Thanks
-Vincent
-Original Message-
From: Michael Mekaail [mailto:[EMAIL PROTECTED]
Sent: mercredi 9 août 2006 04:49
To: users@maven.apache.org
Subject: Cargo-plugin 0.3-SNAPSHOT problem?
Hey,
I'm trying to get the Cargo plugin working with Maven 2. My first
problem was that the ping was timing out after 2000 (20 sec) which was
too short. But this problem is fixed by using Cargo version
0.3-SNAPSHOTand using the tag pingTimeout24/pingTimeout.
However my problem now is that when I do intregration-test I have the
goals in this order:
cargo:start
cargo:deploy
cargo:start Again??!?!
Here is the code that I have in my POM
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
version0.3-SNAPSHOT/version
configuration
waitfalse/wait
container
containerIdtomcat5x/containerId
zipUrlInstaller
urlhttp://www.apache.org/dist/jakarta/tomcat-5/v5.0.30/bin/jakarta-
tomcat-5.0.30.zip/url
installDir${installDir}/installDir
/zipUrlInstaller
timeout12/timeout
outputoutput.log/output
logcargo-log.log/log
/container
configuration
home${project.build.directory}/tomcat5x/container/home
properties
cargo.servlet.port9087/cargo.servlet.port
/properties
/configuration
/configuration
executions
execution
idstart-container/id
phasepre-integration-test/phase
goals
goalstart/goal
goaldeploy/goal
/goals
configuration
deployer
deployables
deployable
groupIdcom.company.project/groupId
artifactIdproject/artifactId
typewar/type
location../project/target/project-1.0.war/location
pingURLhttp://localhost:9087/project-1.0/pingURL
pingTimeout24/pingTimeout
/deployable
/deployables
/deployer
/configuration
/execution
execution
idstop-container/id
phasepost-integration-test/phase
goals
goalstop/goal
/goals
/execution
/executions
/plugin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos
expériences.
http://fr.answers.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Philosophy...
-Original Message- From: Jimisola Laursen [mailto:[EMAIL PROTECTED] Sent: dimanche 6 août 2006 19:49 To: users@maven.apache.org Subject: Re: Maven Philosophy... Scott Battaglia wrote: Projects released under an open source license can qualify for a non-commercial license of Clover: http://www.cenqua.com/clover/licensing.html (its towards the bottom of the page) -Scott I don't know what I was thinking of in my previous post but I wrote non-commercial when I meant commercial. That is, this is for a commercial product - not a non-commercial. That leaves me with Cobertura and Emma. Correct? Another option is to spend some bucks on if it fits your needs. It'll probably cost you less than finding working alternatives but all that depends on your needs I guess. For example if you spend 1 day looking for an alternative it'll already have paid for itself... ;-) I haven't used cobertura nor emma recently so I can't tell you which one is best. The only one I really know is Clover and that's the one I used on business projects. I also use it on oss projects. And I wrote the m1 clover plugin and now the m2 plugin so I'm 100% biased :-) -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cactus plug-in for Maven 2.0
-Original Message- From: Rakesh Kalra [mailto:[EMAIL PROTECTED] Sent: jeudi 3 août 2006 22:12 To: users@maven.apache.org Subject: Cactus plug-in for Maven 2.0 Is any work going on for developing cactus plug-in for Maven 2.0? There has been several discussion thread about this here and on the cactus list. Word had even been started by Kenney but I don't think he's had time to work much on it yet. So any help would be welcome. Basically with the Cargo plugin now available to start/stop/configure containers, the only task left for a cactus plugin would be the cactification. What is the recommended way to integrate with Cactus, while waiting for the plug-in to be available? You could simply use the war plugin to manually cactify your WAR/EAR or you could use the Antrun plugin to call the Cactus Ant tasks. All that said, I haven't tried to use cactus with a m2 build so I'm not the best person to answer this... Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Philosophy...
-Original Message- From: Jimisola Laursen [mailto:[EMAIL PROTECTED] Sent: dimanche 6 août 2006 15:05 To: users@maven.apache.org Subject: RE: Maven Philosophy... vmassol wrote: [snip] FWIW this is currently supported in the Clover plugin. The plugin does this by creating clovered artifacts that it installs in your local repository and swaps a project's dependencies in favor of those clovered one when it finds them. I'm using it on Cargo's build successfully to report on full project coverage. -Vincent [snip] Sadly, Clover is not free for non-commercial use. AFAIK you can easily get a license for non-commercial use. -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo Plugin
Hi Alex, _ From: Alex Turner [mailto:[EMAIL PROTECTED] Sent: dimanche 30 juillet 2006 22:12 To: [EMAIL PROTECTED] Cc: Maven Users List Subject: Re: Cargo Plugin What can I do to help make this happen. This is a priority for me, and I have no problem helping to make it happen Very cool :-) You mean helping on improving the documentation, right? If so, give me your confluence id on http://docs.codehaus.org http://docs.codehaus.org/ and Ill give you access to the cargo wiki so that you can edit any page. The best is for us to discuss all this on the cargo user or dev list. Thanks -Vincent PS: Moving this mail to the cargo dev list. Please follow me there to continue the discussion. Alex On 7/29/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Alex, _ From: Alex Turner [mailto:[EMAIL PROTECTED] Sent: samedi 29 juillet 2006 21:03 To: Maven Users List; [EMAIL PROTECTED] Subject: Re: Cargo Plugin To make it easier, I might break it down into scenarios. In a kind of how do I? format. How do I deploy a war file to a container? How do I deploy a war file exploded to a conatiner? How do I restart a container? This is what we have for the m2 plugin: testCreateCustomDeployable. We don't have it in general though so I believe the problem is in generalizing this to all the different APIs. That's a good idea. I've created a jira issue for this: http://jira.codehaus.org/browse/CARGO-399 The other thing is, I haven't found a way to update my deployment. I want to just copy files that have changes and ask the container to redeploy the web app. This is something ant can do quite easily, and I can't figure out how to do with maven/cargo. Yep, I agree. It is undocumented for now. I have created a jira issue for it: http://jira.codehaus.org/browse/CARGO-398 Now all we need are contributors to help us and speed this up. Thanks for the feedback -Vincent Thanks for all the great support, Alex. On 7/29/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Alex, -Original Message- From: Alex Turner [mailto: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Sent: samedi 29 juillet 2006 06:46 To: Maven Users List Subject: Re: Cargo Plugin Thanks for the pointer - the documentation isn't the easiest to follow, but I figured it out. What do you think would the single most important point to improve it? [snip] Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo Plugin
Hi Alex, -Original Message- From: Alex Turner [mailto:[EMAIL PROTECTED] Sent: samedi 29 juillet 2006 06:46 To: Maven Users List Subject: Re: Cargo Plugin Thanks for the pointer - the documentation isn't the easiest to follow, but I figured it out. What do you think would the single most important point to improve it? [snip] Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cargo Plugin
Hi Alex, _ From: Alex Turner [mailto:[EMAIL PROTECTED] Sent: samedi 29 juillet 2006 21:03 To: Maven Users List; [EMAIL PROTECTED] Subject: Re: Cargo Plugin To make it easier, I might break it down into scenarios. In a kind of how do I? format. How do I deploy a war file to a container? How do I deploy a war file exploded to a conatiner? How do I restart a container? This is what we have for the m2 plugin: testCreateCustomDeployable. We dont have it in general though so I believe the problem is in generalizing this to all the different APIs. Thats a good idea. Ive created a jira issue for this: http://jira.codehaus.org/browse/CARGO-399 The other thing is, I haven't found a way to update my deployment. I want to just copy files that have changes and ask the container to redeploy the web app. This is something ant can do quite easily, and I can't figure out how to do with maven/cargo. Yep, I agree. It is undocumented for now. I have created a jira issue for it: http://jira.codehaus.org/browse/CARGO-398 Now all we need are contributors to help us and speed this up. Thanks for the feedback -Vincent Thanks for all the great support, Alex. On 7/29/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Alex, -Original Message- From: Alex Turner [mailto: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Sent: samedi 29 juillet 2006 06:46 To: Maven Users List Subject: Re: Cargo Plugin Thanks for the pointer - the documentation isn't the easiest to follow, but I figured it out. What do you think would the single most important point to improve it? [snip] Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2-snapshot error
-Original Message- From: Matilda Robert [mailto:[EMAIL PROTECTED] Sent: jeudi 27 juillet 2006 15:20 To: 'Maven Users List' Subject: RE: M2-snapshot error Hi Vincent, It works now! I had to go in and manually delete the cargo files and then run the mvn clean command to get it to work. Thank for the help. FYI, just doing the mvn clean -cpu or -u at first didn't work (for me). Glad to know it worked. Thanks -Vincent -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 3:31 AM To: Maven Users List; [EMAIL PROTECTED] Subject: RE: M2-snapshot error Vincent Massol wrote on Wednesday, July 26, 2006 7:25 PM: Done. Try it. Make sure you use -cpu or -u (can never recall which one) or delete the cargo files in your local repo. Well, infact -cpu should update the plugins, while -U should look for SNAPSHOTs (see mvn --help). For me its working the other way round though ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code coverage with AspectJ?
Hi Howard, -Original Message- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 17:19 To: Maven Users List Subject: Code coverage with AspectJ? Does anyone know how to generate a code coverage report when using AspectJ in a project? The Clover plugin wants to rewrite and recompile the code, which probably won't play well with all things aspect. I haven't tried it but that should be a good test to add to the clover plugin test suite. There are various possibilities (clover applied before aspectj, aspectj applied before clover, using aspectj to instrument sources, using aspectj to instrument classes). Let's try to imagine what's going to happen. Scenario 1: Clover before AspectJ * clover creates new sources in target/clover/src * aspectj plugin thinks the project sources are in target/clover/src and instrument those I don't see any issue. Scenario 2: AspectJ before Clover * AspectJ instrument sources. I haven't used the aspectj plugin for m2 but I guess it generates classes thus clover is going to simply run but on the original sources and not on the aspectified. Note that this may or may not be what you want :-) In any case I don't any real issue. The scenario 1 sounds the best though. Simply make sure you execute clover:instrument before the aspectj goal in your POM. Any specific issue you can foresee? Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2-snapshot error
Hi Matilda, I did a cargo snapshot deploy at around that time and the deploy failed (some http connection failed in maven). I did a new deploy and it worked. However it's possible that it cause some problem. I'm going to clean up the repo and do a deploy again. I've found in the past that if there's a problem during the deploy the repository can be left in an unstable state. Thanks -Vincent -Original Message- From: Matilda Robert [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 18:45 To: users@maven.apache.org Subject: M2-snapshot error Hi all, Is anyone else having a problem trying to access cargo m2 snapshot repository? I didn't start having this problem until yesterday about 2 pm. Before yesterday afternoon everything ran fine now, I am getting this error while compiling: 594$ [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'cargo'. [INFO] -- -- [INFO] Building Maven Webapp Archetype [INFO]task-segment: [cargo:start] [INFO] -- -- Downloading: http://snapshots.repository.codehaus.org/org/codehaus/cargo/cargo-core- api-c ontainer/0.9-SNAPSHOT/cargo-core-api-container-0.9-20060726.094159-3.pom [WARNING] Unable to get resource from repository cargo m2 snapshot repository (http://snapshots.repository.codehaus.org) [INFO] [cargo:start] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to create a WebLogic 8.x standalone configuration Invalid configuration dir [file:/X:/XX/XX/xxx//target/weblogic8x/]. The configuration dir must point to an empty directory. Note that everything in the configuration dir will get deleted by Cargo. [INFO] [INFO] Trace org.codehaus.cargo.container.ContainerException: Failed to create a WebLogic 8.x standalone configuration at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguration. co nfigure(AbstractLocalConfiguration.java:187) ... .. . [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Wed Jul 26 12:33:13 EDT 2006 [INFO] Final Memory: 4M/8M [INFO] Any help would be greatly appreciated. Thanks in advanced, Matilda - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2-snapshot error
Done. Try it. Make sure you use -cpu or -u (can never recall which one) or delete the cargo files in your local repo. -Vincent -Original Message- From: Matilda Robert [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 19:12 To: 'Maven Users List'; [EMAIL PROTECTED] Subject: RE: M2-snapshot error Thank you! Matilda -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 12:53 PM To: 'Maven Users List' Subject: RE: M2-snapshot error Hi Matilda, I did a cargo snapshot deploy at around that time and the deploy failed (some http connection failed in maven). I did a new deploy and it worked. However it's possible that it cause some problem. I'm going to clean up the repo and do a deploy again. I've found in the past that if there's a problem during the deploy the repository can be left in an unstable state. Thanks -Vincent -Original Message- From: Matilda Robert [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 18:45 To: users@maven.apache.org Subject: M2-snapshot error Hi all, Is anyone else having a problem trying to access cargo m2 snapshot repository? I didn't start having this problem until yesterday about 2 pm. Before yesterday afternoon everything ran fine now, I am getting this error while compiling: 594$ [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'cargo'. [INFO] -- -- [INFO] Building Maven Webapp Archetype [INFO]task-segment: [cargo:start] [INFO] -- -- Downloading: http://snapshots.repository.codehaus.org/org/codehaus/cargo/cargo-core- api-c ontainer/0.9-SNAPSHOT/cargo-core-api-container-0.9-20060726.094159-3.pom [WARNING] Unable to get resource from repository cargo m2 snapshot repository (http://snapshots.repository.codehaus.org) [INFO] [cargo:start] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to create a WebLogic 8.x standalone configuration Invalid configuration dir [file:/X:/XX/XX/xxx//target/weblogic8x/]. The configuration dir must point to an empty directory. Note that everything in the configuration dir will get deleted by Cargo. [INFO] [INFO] Trace org.codehaus.cargo.container.ContainerException: Failed to create a WebLogic 8.x standalone configuration at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguration. co nfigure(AbstractLocalConfiguration.java:187) ... .. . [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Wed Jul 26 12:33:13 EDT 2006 [INFO] Final Memory: 4M/8M [INFO] Any help would be greatly appreciated. Thanks in advanced, Matilda - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. __ _ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code coverage with AspectJ?
-Original Message- From: Kaare Nilsen [mailto:[EMAIL PROTECTED] Sent: mercredi 26 juillet 2006 19:53 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 26/07/06, Jason Chaffee [EMAIL PROTECTED] wrote: I use cobetura and load-time weaving during unit-tests to do this. To use load-time weaving you must fork at least once and provide the javaagent as an argline -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 8:42 AM To: 'Maven Users List' Subject: RE: Code coverage with AspectJ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: mercredi 26 juillet 2006 17:29 To: Maven Users List Subject: Re: Code coverage with AspectJ? On 7/26/06, Howard Lewis Ship [EMAIL PROTECTED] wrote: Does anyone know how to generate a code coverage report when using AspectJ in a project? The Clover plugin wants to rewrite and recompile the code, which probably won't play well with all things aspect. seems not possible: [quote] Indeed running AspectJ AFTER Clover works. I'm using that for now, so that I at least have SOME Clover data. The thing I would like though, is to run AspectJ BEFORE Clover runs, so I also have Clover data on the AspectJ-sources! As I see it, there are 2 ways to do this: 1) AspectJ weaves his new files and writes them out as sources so Clover can work on them. The problem here will be that Clover can't show the reports on AspectJ-files, but rather on the weaved files. Why not? If you point the Clover plugin to the generated sources it should work fine, no? I guess I'd need to try it. It's a solution, but what would be really great is: 2) Clover examines the AspectJ sources and adds his statements to those files. Then AspectJ can do his normal thing and Clover's reports should show the coverage in the correct files and calculate the EXACT amount of times the statements have been called. I don't understand this solution. Is clover running before aspectj in this case? If so then we're back to the first solution above, no? Unfortunately I already heard from Cenqua that atm Clover doesn't know how to handle AspectJ sources... So I think that the plugin will have the same problems... Ah maybe there's some issue. If someone could show me a very simple aspectj project (one simple class, one aspect, one test and a POM using the aspectj plugin) then I could add it to the clover plugin's test suite and try it out. You will find some here : http://svn.codehaus.org/mojo/trunk/mojo/aspectj-maven- plugin/src/test/projects/ But as Carlos mentioned. Clover and aspectJ is not really compatible Thanks for the link. Could you elaborate just a little more about the incompatibility before I spend too much time looking into it? :-) Thanks -Vincent Is there a Maven2 plugin for emma or cobetura? cobertura, and it plays well with aspectj afaik, you have to make sure the aspectj plugin doesn't recompile from sources for what I read in the cobertura mailing list -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ _ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez un nouveau moyen de poser toutes vos questions
RE: clover:save-history goal for 2.x?
Hi Michael, -Original Message- From: Michael Waluk [mailto:[EMAIL PROTECTED] Sent: jeudi 20 juillet 2006 22:41 To: Maven Users List Subject: Re: clover:save-history goal for 2.x? Thank you Vincent! I can now generate the history save points, but I was wondering if we can have Maven generate that historical report (HTML) with the nice-looking chart. I think we can use an Ant task to do it like we used to pre-Maven but I was hoping that there would be a plugin configuration point that would cause this historical report page to be generated (and ideally linked to in the standard clover report). Can you let me know if using Ant is the only way to do it? Could you please open a jira issue for this and I'll look into it? Thanks -Vincent On 6/26/06, Vincent Massol [EMAIL PROTECTED] wrote: Michael, Just to let you know that I've released v2.2 of the clover plugin today. It should be on ibiblio in a few hours. -Vincent -Original Message- From: Michael Waluk [mailto:[EMAIL PROTECTED] Sent: vendredi 23 juin 2006 20:41 To: Maven Users List Subject: clover:save-history goal for 2.x? Hi, I was just wondering if anyone (VM?) knows if/when the historical data report will be available in this plugin for Maven 2.x. I don't mean to be pushy, but I was just curious. Or alternatively is anyone creating it by binding an equivalent ant call(s)? Thanks, Michael __ _ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to generate clover historical HTML report?
Dup of previous email... -Vincent -Original Message- From: Michael Waluk [mailto:[EMAIL PROTECTED] Sent: lundi 24 juillet 2006 17:03 To: Maven Users List Subject: How to generate clover historical HTML report? Hi, With the latest version of the clover plugin I can now generate the history save points, but I was wondering if we can have Maven generate that historical report (HTML) with the nice-looking chart. I think we can use an Ant task to do it like we used to pre-Maven but I was hoping that there would be a plugin configuration point that would cause this historical report page to be generated (and ideally linked to in the standard clover report). Can you let me know if using Ant is the only way to do it? Thanks, Michael ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: post-integration-test not run if integration-test fails (problem for continuum)
Hi Eric, -Original Message- From: Eric Brown [mailto:[EMAIL PROTECTED] Sent: mardi 25 juillet 2006 18:54 To: Maven Users List Subject: post-integration-test not run if integration-test fails (problem for continuum) I have to start up 2 servers and a bunch of webservices in pre- integration-test. Then I run my integration tests. Then post- integration-test stops my servers. However, if some of my integration tests fail, maven exits and does not stop my services. Despite being annoying when I'm just running my tests, it is a real problem if I ask continuum to run my integration tests as it leaves the servers running on my continuum box if any test fails. Is there a maven solution to this besides writing a shell script on continuum? My colleague tried using mvn -fae, but that doesn't solve the problem either. I've had this problem too which is why I'm currently recommending to use the Cargo Java API from your own JUnit test, as described on http://cargo.codehaus.org/Functional+testing. This allows you to control the start and stop of your containers from within your tests and you don't need the pre-it and post-it phases. Hope it helps, -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using continuum for building cargo?
Ok, I've fixed all places in Cargo's build that go to the tmp dir except one
(this is when we download the containers). All modules are building except
the one that uses the tmp dir and the error is:
Caused by: in cargo code: java.io.FileNotFoundException:
/tmp/cargo/installs/jetty-6.0.0beta16.zip (Permission denied)
at org.apache.tools.ant.taskdefs.Get.execute(Get.java:267)
at
org.codehaus.cargo.container.installer.ZipURLInstaller.doDownload(ZipURLInst
aller.java:244)
at
org.codehaus.cargo.container.installer.ZipURLInstaller.download(ZipURLInstal
ler.java:211)
... 34 more
Caused by: java.io.FileNotFoundException:
/tmp/cargo/installs/jetty-6.0.0beta16.zip (Permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at org.apache.tools.ant.taskdefs.Get.execute(Get.java:216)
... 36 more
I really think there's a permission issue (it says permission denied) when
it tries to write to that /tmp dir.
I can't moved this to any target/ dir as that would mean re-downloading the
different containers at every build which is just wrong and would be way too
long.
Any idea?
Thanks
-Vincent
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: dimanche 23 juillet 2006 10:11
To: 'continuum-users@maven.apache.org'
Subject: FW: Using continuum for building cargo?
Sure, I'm the first one to tell people who email me this :-) I thought
this was more an infra question for codehaus/mergere.
So, anyone on the list has access to the Codehaus continuum machine? Or
any other idea?
Thanks
-Vincent
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: dimanche 23 juillet 2006 03:55
To: [EMAIL PROTECTED]
Cc: 'Emmanuel Venisse'
Subject: Re: Using continuum for building cargo?
could we take this over to the users@ or dev@ list? We're trying to
build a bigger community around Continuum, and answering each others
questions is a part of that. Not to metnion having a public archive of
the problem in case others encounter similar circumstances...
Thanks,
Brett
On 23/07/2006 6:06 AM, Vincent Massol wrote:
Hi Brett,
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: vendredi 7 juillet 2006 08:13
To: Vincent Massol
Cc: 'Emmanuel Venisse'
Subject: Re: Using continuum for building cargo?
It runs as nobody, and is successfully creating the directories:
drwxr-xr-x 10 nobodynobody 4096 Jul 6 03:04 cargo
(which contains an empty installs directory).
There are also a bunch of other cargo temp files - missing some
deleteOnExit()s perhaps?
I've progressed a bit but not much. I've fixed this error but I cheated
as I
removed the need for creating a tmp file. However it's not failing in
another module which also creates a tmp file (see
http://tinyurl.com/q3jra).
It's really as if there were some issues creating files. I don't have
access
to the machine. I don't think this has to do with the fact the machine
is on
a *nix os as there are some other cargo committers on *nix and they've
never
reported a problem.
I've checked the code and it calls a mkdirs() which is returning false
so we
can't know the real reason. The JDK code for mkdirs() is hiding the
underlying IOException error:
public boolean mkdirs() {
if (exists()) {
return false;
}
if (mkdir()) {
return true;
}
File canonFile = null;
try {
canonFile = getCanonicalFile();
} catch (IOException e) {
return false;
}
String parent = canonFile.getParent();
return (parent != null)
(new File(parent, fs.prefixLength(parent)).mkdirs()
canonFile.mkdir());
}
Thus I'm pretty sure there must be some kind of permissions issues.
Any idea on how to debug this?
Thanks a lot
-Vincent
On 7/07/2006 1:11 AM, Vincent Massol wrote:
Hi Brett,
I've added cargo projects but the build is failing and the reason
seems
to
be because the user under which continuum runs does not have the right
to
access the /tmp directory. Could that be possible?
Cargo requires the usage of a tmp directory (for storing the
downloaded
container installations for example. This directory must be persistent
across builds as otherwise containers distributions will be downloaded
every
time which will take forever). Cargo uses ${java.io.tmpdir} as the tmp
dir.
I don't have shell access on this machine. Do you think you could
verify
/tmp permissions on this machine?
Thanks a lot
-Vincent
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: mercredi 5 juillet 2006 08:50
To: 'Brett Porter
Cargo uberwar PITA (was RE: Converting AppFuse to a Maven 2 Project)
Hi Alex, -Original Message- From: Alex Shneyderman [mailto:[EMAIL PROTECTED] Sent: mercredi 19 juillet 2006 13:42 To: Maven Users List Subject: Re: Converting AppFuse to a Maven 2 Project [snip] [...] so take a look at cargo:uberwar (cargo.codehaus.org). It allows for custom merging callbacks. Although a pain in an ass to set up (hint: use latest snapshot) That's some interesting feedback! It would be real nice if you could send an email to the cargo list explaining what you think is painful and how you think it could be improved. Thanks -Vincent ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] Maven Deployment Using Cargo To WebSphere
Hi Peter, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: lundi 17 juillet 2006 10:40 To: users@maven.apache.org Subject: [M2] Maven Deployment Using Cargo To WebSphere Hi I have just reading the documentation looking for remote deployment to IBM WebSphere at http://cargo.codehaus.org/Container and much to my surprise Does Cargo support Websphere deployment? Or how do you perform deployment to Websphere? This would be better asked on the Cargo mailing list. It's not supported yet but several contributors have expressed interest for working on it and Ahmed has provided a first patch. See http://jira.codehaus.org/browse/CARGO-147 Thanks -Vincent ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven book: feedback
Hi Sebastien, I'm glad that you liked the m1 book ;-) but I'm sorry that you don't like the new m2 one... There are probably several reasons. One of them may be that it's hard to write with a consistent voice and consistent progression when several authors write at the same time. OTOH this has allowed us to cover an important variety of topics and to release the book when it was needed. I guess the other hard part when we wrote the m2 book is that m2 was and still is evolving. This is one reason why an online format is a good choice. So I guess that in order to improve in the next release of the m2 book we should get someone to review/reorder/rewrite the junctions between the different chapters to get a more seamless flow between them and so that the progression remains constant. What would make this even easier would be to get help from the community to tell us precisely where things should be improved. AFAIK there's no Maven2 Developer's Notebook in the pipeline and I think we should be able to improve this one over time. It's an online book and thus has the power of being modified more easily. Thanks for your feedback. -Vincent -Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: samedi 15 juillet 2006 18:11 To: Maven users list Subject: Maven book: feedback Hi, I'm currently in the process of reading Better builds with Maven and to be honnest... I'm quite disappointed. I found Maven Developer's notebook for Maven 1 excellent, and I said it a few times on this list. It's even one of the books I used the most often for some time. And when Vincent Massol announced at JavaPolis in last december that a free Maven2 book was on its way, I was very excited, because I dreamt of such a good book combined with all the marvels of Maven2 that he demonstrated. When I started reading Better Builds with Maven for the first time, just after it was released, I was quickly annoyed by the number of errors and the inconsistence of sample source code with what was reproduced in the book. So I waited for the updated version with corrected errata and I'm reading it right now... and I'm somewhat disappointed because it puzzles me more than anything. It starts off with a very basic introduction to what is Maven, how it was designed... and suddenly, it jumps straight up to web services and very elaborated samples that have nothing to do with a progressive and pragmatic approach. Even worse: samples are full of noise concerning exotic plugins and their configuration and the structure is very... weird. I'm not into free criticism, but I think feedback is important, even when it's negative. And based on that, I would like to know if there is a Maven2 Developer's Notebook in the pipeline, something more pragmatic, something simpler, something that would give justice to the beauty of Maven2. Because I'm afraid this one could frighten new users more than encourage them to abandon their old Ant scripts. Because I would even be ready to pay a few tens of bucks just to get the same experience I had with the first O'Reilly volume. And because obviously, I miss a lot of knowledge to write it myself. Once again, don't take me wrong: this is not free criticism, this is just my humble yet negative feedback as a user who's been using Maven1 for about a year and a half on personal and professional projects, and who's looking for an efficient and comprehensive reference book to migrate to Maven 2 and understand its changes pragmatically and progressively. -- Sébastien Arbogast http://www.sebastien-arbogast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven book: feedback
I think it's hard to do when you start from scratch. However now that there's a first version I believe it could work. We may still need some kind of workflow and review process before accepting changes but yes it could work. OTOH there's already open documentation on the Maven wiki and in Maven's svn. It's not because it's open that people contribute more or that the quality is better... The book belongs to Mergere, who has sponsored it. Thus it's not my choice nor the community but rather Mergere's. I'm personally open to all suggestions. Thanks -Vincent -Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: dimanche 16 juillet 2006 21:39 To: Maven Users List Subject: Re: Maven book: feedback Why not trying to innovate then? Why not getting the source code of the book available to the community and make its improvement a community effort? It could be an interesting experiment: using the current version as a working basis, you could allow people to pinpoint parts that could be improved, and others could propose rewritten sections. Technically, you could use a CMS, with one page for each subsection of the book, and people could leave comments about each section. Sometimes people could gather several remarks and rewrite the section to take them into account, thus creating a new version of the section. And that way, the book would be more dynamic andit would be easier to update it as Maven evolves. I've already done that kind of things with Drupal and it gave quite good results. What do you think ? Open Source documentation ? 2006/7/16, Vincent Massol [EMAIL PROTECTED]: Hi Sebastien, I'm glad that you liked the m1 book ;-) but I'm sorry that you don't like the new m2 one... There are probably several reasons. One of them may be that it's hard to write with a consistent voice and consistent progression when several authors write at the same time. OTOH this has allowed us to cover an important variety of topics and to release the book when it was needed. I guess the other hard part when we wrote the m2 book is that m2 was and still is evolving. This is one reason why an online format is a good choice. So I guess that in order to improve in the next release of the m2 book we should get someone to review/reorder/rewrite the junctions between the different chapters to get a more seamless flow between them and so that the progression remains constant. What would make this even easier would be to get help from the community to tell us precisely where things should be improved. AFAIK there's no Maven2 Developer's Notebook in the pipeline and I think we should be able to improve this one over time. It's an online book and thus has the power of being modified more easily. Thanks for your feedback. -Vincent -Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: samedi 15 juillet 2006 18:11 To: Maven users list Subject: Maven book: feedback Hi, I'm currently in the process of reading Better builds with Maven and to be honnest... I'm quite disappointed. I found Maven Developer's notebook for Maven 1 excellent, and I said it a few times on this list. It's even one of the books I used the most often for some time. And when Vincent Massol announced at JavaPolis in last december that a free Maven2 book was on its way, I was very excited, because I dreamt of such a good book combined with all the marvels of Maven2 that he demonstrated. When I started reading Better Builds with Maven for the first time, just after it was released, I was quickly annoyed by the number of errors and the inconsistence of sample source code with what was reproduced in the book. So I waited for the updated version with corrected errata and I'm reading it right now... and I'm somewhat disappointed because it puzzles me more than anything. It starts off with a very basic introduction to what is Maven, how it was designed... and suddenly, it jumps straight up to web services and very elaborated samples that have nothing to do with a progressive and pragmatic approach. Even worse: samples are full of noise concerning exotic plugins and their configuration and the structure is very... weird. I'm not into free criticism, but I think feedback is important, even when it's negative. And based on that, I would like to know if there is a Maven2 Developer's Notebook in the pipeline, something more pragmatic, something simpler, something that would give justice to the beauty of Maven2. Because I'm afraid this one could frighten new users more than encourage them to abandon their old Ant scripts. Because I would even be ready to pay a few tens of bucks just to get the same experience I had with the first O'Reilly volume. And because obviously, I miss a lot of knowledge to write it myself
Re: EJB3 Web project with cargo, jetty6
Hi Tony, On 7/14/06, Tony Hillerson [EMAIL PROTECTED] wrote: Hello all, I have a project that will use EJB3.0, and as far as I know only a few containers support that. I'm using jBoss now. My question is along the lines of the Improving Web Development Productivity section of the Maven Book. I've tried the jetty6 plugin and it's perfect for development; it lets me make changes to the working copy of the source, test them locally, and check them in. I don't have to deploy every time I make a change to the code, etc. The only problem is that I don't think the EJB3.0 part will work with jetty. Am I wrong there? Is there any way to let me easily deploy and view my web file changes with the cargo plugin somewhat like the jetty6 plugin? Can I start a development server, make working copy changes and see them without running maven and deploying every time I make a change? Yes this is possible with the cargo m2 plugin (for containers supporting expanded wars). Simply use the location element to point to where your exploded war file is located (i.e. src/main/webapp). Please use the cargo mailing list if you need more help. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issue with maven 2.0.3, cargo and weblogic 8.x
Hi Bryan, -Original Message- From: Pauquette, Bryan [mailto:[EMAIL PROTECTED] Sent: jeudi 13 juillet 2006 21:40 To: Maven Users List Subject: Issue with maven 2.0.3, cargo and weblogic 8.x I am running into an issue with maven2.0.4 and cargo and deploying an ejb-jar to weblogic8x. Has anyone seen a similar issue? It looks like the name of the artifact is being incorrectly ascertained. The extension is not being updated to .jar (instead it uses .ejb) I think the relevant code is here http://svn.cargo.codehaus.org/browse/~raw,r=1061/cargo/cargo/trunk/exten sions/maven2/src/main/java/org/codehaus/cargo/maven2/Deployable.java Is this a bug or am I doing something wrong? This question would be best asked on the cargo mailing list... That said I think I know the problem. You seem to be using version 0.1 of the Cargo Maven2 plugin which did not support EJB. If you try version 0.2 it should work fine, except that the current implementation for WebLogic doesn't support deploying EJBs (the only current implementation supporting EJBs is JBoss). That said, anyone with knowledge of how EJB deployment works in WebLogic should be able to provide a patch very easily and the Cargo team would be happy to work with you if you were interested to help. Let's talk on the cargo list. See http://cargo.codehaus.org/Mailing+Lists Thanks -Vincent [snip] ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Email Limiting?
Hi Mark, I'd love this too. See http://jira.codehaus.org/browse/CONTINUUM-634. You can even vote for it ;-) Unfortunately there's no fix for right now for this issue meaning there's no plan to include it as yet. Thanks -Vincent -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reynolds Sent: mardi 4 juillet 2006 23:14 To: continuum-users@maven.apache.org Subject: Email Limiting? We have Continuum checking SVN once per minute so our build will begin very quickly after someone does a commit. Occasionally there is some problem, for instance, where something happens with Continuum's SVN working copy requiring cleanup to be run. In this case, Continuum will send out approximately 10 error emails per minute to all of our users. If this happens shortly after everyone has left for the day, there can be quite a large number of emails in everyone's inbox!! Is there some way to limit the emails that Continuum will send out? If not, this would be a worthy enhancement. Thanks. -- Mark R ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
RE: Deployment problem with Jboss
Hi Vinay, This looks like a cargo issue. You should post on the Cargo list so that you can get help. When you do so it would be good to post your pom.xml and attach the log files to your mail. Thanks -Vincent -Original Message- From: Vinay Kumar [mailto:[EMAIL PROTECTED] Sent: mardi 27 juin 2006 11:53 To: users@maven.apache.org Subject: Deployment problem with Jboss Hi All, When I am deploying my application with Jboss Application Server , After starting Jboss Containers it stuck and in log in giving following warning: = 13:42:28,166 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml 13:43:58,037 WARN [Configurator] No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/C:/Documents%20and%20Settings/vinayzk/Local%20Settings/Temp/carg o/24851/tmp/deploy/tmp302Utilization-exp.war/WEB-INF/lib/ehcache- 1.1.jar!/ehcache-failsafe.xml Anyone have idea about this. Thanks Vinay ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Clover Plugin 2.2 for Maven 2 Released
The Maven team is pleased to announce the release of the Maven Clover Plugin, version 2.2 http://maven.apache.org/plugins/maven-clover-plugin/ You can run mvn -U to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clover-plugin/artifactId version2.2/version /plugin Changes: http://tinyurl.com/pm7fc Release Notes - Maven 2.x Clover Plugin - Version 2.2 ** Bug * [MCLOVER-35] - Missing a test-jar dependency at compile time. * [MCLOVER-36] - Plugin should locate clover artifact based on groupId+artifactId and not only on artifactId * [MCLOVER-39] - clover:check and clover:log should ignore projects with no Clover database rather than error out ** Improvement * [MCLOVER-41] - clover:check and clover:log should operate on all Clover databases ** New Feature * [MCLOVER-20] - Add historical reporting Have fun! -The Maven team ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
