integrationUnitTest
Hi, I asked this question last week, but received no response. So here it is again slightly rephrased. The integrationUnitTestSourceDirectory and integrationUnitTest elements are described in the project schema. They are defined exactly the same as the unitTestXXX elements and, in fact, several of the project.xml's within Maven itself contain them. However, they are not used anywhere and only integrationUnitTestSourceDirectory is actually implemented as a property in Build.java, integrationUnitTest is not. Are the integrationUnitTestXXX elements deprecated or are they in process of being implemented for a future Maven version? We would like to take advantage of these elements to segregate our tests (via different includes/excludes) into 2 separate categories: routine tests and more extensive integration tests. However, we are unable to use the integrationUnitTest element because it is not currently implemented in Build.java. The only avenue I see is to create a separate pom in each project to define the integration tests. Any suggestions for a cleaner or better way to handle this? -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: integrationUnitTest
Hi Jeffrey, If you dig back into the logs there was someone working to do just that and reuse the test plugin. I'm not sure of the status which is why I didn't respond the first go around. I have the same use case is you, we want our slower running 'program integration tests' to be available but not run with our 'unit tests'. There was talk of offering something like any number of levels of tests, not just two. Thanks for the hint- I just reviewed the relavent discussion threads from January. However, it does not seem that there is any active work going on in this area. I do not see any further mention from the person that said he had something for beta7. I've looked a bit more at our situation. Currently, we have all our unit and integration tests for a particular project stored in the same directory tree. This is a holdover from Ant when we simply ran all the tests at night via a cron job. So, our unit tests can be considered as a strict subset of the integration tests. So, what I am now thinking is that our project.xml would contain the unitTest fileset definition for all the tests, ie. the integration tests. Then we could define a project property that contains an additional exclude pattern that will refine the integration tests into the unit tests. I am not sure if it is possible to modify the pom programmaticly, but I am going to try doing something like: j:set var=dummy value=pom.build.unitTest.addExclude(myExcludePatternProp) / in a test pregoal. This might serve my needs adequately for now. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- On Mon, 17 Mar 2003 15:56:19 -0500, David Zeleznik [EMAIL PROTECTED] said: Hi, I asked this question last week, but received no response. So here it is again slightly rephrased. The integrationUnitTestSourceDirectory and integrationUnitTest elements are described in the project schema. They are defined exactly the same as the unitTestXXX elements and, in fact, several of the project.xml's within Maven itself contain them. However, they are not used anywhere and only integrationUnitTestSourceDirectory is actually implemented as a property in Build.java, integrationUnitTest is not. Are the integrationUnitTestXXX elements deprecated or are they in process of being implemented for a future Maven version? We would like to take advantage of these elements to segregate our tests (via different includes/excludes) into 2 separate categories: routine tests and more extensive integration tests. However, we are unable to use the integrationUnitTest element because it is not currently implemented in Build.java. The only avenue I see is to create a separate pom in each project to define the integration tests. Any suggestions for a cleaner or better way to handle this? -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [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: build time vs. runtime dependency
Hi,
FWIW, we faced a similar problem related to our unit tests. We have
dependencies on a large test framework built ontop of jUnit that we want
included in the test compilation and runtime path, but omitted from the
normal classpath. We hacked this by putting these additional dependencies
into a separate pom that we have standardized called project-tests.xml. Our
custom plugin then registers test pre and post goals that read this pom and
add/remove it from Maven's classpath. Here is an example:
goal name=addTestDependencies
available
property=testPomPresent
file=${basedir}/project-tests.xml /
j:if test=${testPomPresent}
j:set var=testPathX
value=${pom.getAntProject().getReference('test.path')}X/
j:if test=${testPathX == 'X'}
!-- Read the POM that describes test-specific dependencies and then
verify those dependencies from the repo. --
m:pom projectDescriptor=${basedir}/project-tests.xml
var=testPom/
j:set var=dummyVar value=${testPom.verifyDependencies()} /
path id=test.path path=${testPom.getDependencyClasspath()} /
/j:if
!-- Save Maven's current class path as a string. Because it is a true
Ant path object, we cannot simply declare a new variable that
references the same object we are about to change. Also, we
cannot
simply use the project's dependencyClasspath attribute because
other
goals, such as clover, also make modifications to Maven's
dependency
class path that we must preserve. --
j:set
var=savedPath
value=${pom.getAntProject().getReference('maven.dependency.classpath').toSt
ring()} /
!-- Add test-specific dependencies to the project's Ant-style
classpath
structure. Note that this only modifies the Ant path object and
does
not change the project's dependencyClasspath attribute. --
m:addPath id=maven.dependency.classpath refid=jviews.test.path /
/j:if
/goal
goal name=removeTestDependencies
j:if test=${testPomPresent == 'true'}
!-- Restore Maven's classpath by redefining it. --
path id=maven.dependency.classpath
pathelement path=${savedPath} /
/path
/j:if
/goal
preGoal name=test:compile
attainGoal name=addTestDependencies /
/preGoal
postGoal name=test:compile
attainGoal name=removeTestDependencies /
/postGoal
I worked this out the hard way because it was one of our first needs when we
started migrating to Maven. Personally, I wish there was an easier and more
general-purpose way to segregate and group dependencies and also have
control over when they are verified. It is also getting to the point where
we are considering writing our own DependencyVerifier subclass so that we
can have a range of snapshot-like dependencies with finer grained control
over how each type is resolved.
--
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
-Original Message-
From: Charles Chan [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2003 9:30 AM
To: maven-user
Subject: build time vs. runtime dependency
Hi, in Maven, we have only one way of specifying
dependency. In some cases, a project may have
different dependencies at runtime and at compile time.
I can think of two examples:
1. A project that uses a dependent library that
guarantees backward API compatibility. The project may
not want to use any new API but they want to run
against any improved code.
2. A dependency library can be split into an API
portion and an implementation portion. To prevent
anyone from using the implementation portion, one may
NOT want to have any implementation class in the
compile classpath.
Do you think they are valid scenarios? How would Maven
deal with them?
Charles
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.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]
Integration vs Smoke Tests
Hi, We are at the point in our migration to Maven where we need to segregate the quick smoke tests for each module from the lengthy tests that can run for close to an hour. Our idea is that the full test suite would only be run automatically when a release is about to be deployed or if the user explicitly asks to run them. So, I have noticed in the project DTD and in Build.java that there is are integrationUnitTest and integrationUnitTestSourceDirectory elements defined, but they do not seem to be used nor referenced anywhere. Are these elements deprecated, new, ??? How are others separating the module smoke tests from the lengthier tests that are too cumbersome to run everytime you want to create a jar? -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: build time vs. runtime dependency
Depenedencies have a type attribute in the POM, but I don't think that it is used at the moment... ideally plugins could set up a separate classpath when, for example, type == 'test' || type == null. Builds could use type == 'compile' || type == null. I'm not sure - what else is type used for at the moment? I noticed it renaming JARs sometimes, so I took it out... AFAIK, the type attribute determines the name of the subdirectory in the remote repo (with an 's' appended) where the artifact is stored. So a jar dependency, the default type, is obtained from the jars subdir. A pom dependency is obtained from the poms subdir, etc. Also, the type is used as the default extension of the artifact. Maven verifies and downloads all dependency types, but jars are treated special because they are added to the maven.dependency.classpath. Conversely, you pass the type attribute, with the 's' appended, to the deploy:artifact tag to specify the subdir on the central repo to deploy to. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clover plugin and maxmemory
Hi, Pop a patch into Jira and we'll get it commited. Please explain. Are you requesting that I simply log a wish with a description of my proposed changes? Or is there a special location and format to upload diff-style patches? -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- We have been trying to use the Clover plugin with beta 8 and keep getting out-of-memory errors. Looking at the plugin.jelly, it seems that the vm is forked but there is no provision for specifying the maxmemory attribute. It seems to me that this would be essential for anyone working with even a moderate sized project. The CVS repository shows no change in this since beta8 was released. It seems like our only solution is to provide an overridden clover goal to all our developers :-( Is there a better way? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Overriding goals in imported jelly script
Hi, We have a strong need to completely override certain standard goals defined by the plugins. In these cases, attaching preGoals or postGoals is not enough. If we define the overriden goals in our project's maven.xml, all works fine. However, we want to centralize these goal overrides by breaking them out into a separate jelly script and then jelly:import'ing this shared script from our maven.xml. This does not seem to work at all, even with the inherit attribute set true. However, unique new goals that are defined in our imported jelly script are registered and do work fine. So, it seems that jelly script that has been imported by maven.xml can define new goals, but cannot override already defined goals. Is this true and is there any workaround for this? Thanks in advance, -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cleaning up Maven's caches after plugin:install
[snippage] plugin will be registered and work properly. I have encapsulated this logic into the following postgoal: [snip code] I've committed the change to the plugin:install. Wow, thanks! Honestly, I wasn't sure if deleting the caches out from underneath Maven was really safe. But, Maven seemed to treat the situation gracefully, so we kept it. I could imagine that there might be some runtime data structures that need to cleaned up or reinitialized as well so that they stay in sync with the caches. Any thoughts on this? I suppose a test case could be written to test for plugin reinstallation more formally: - plugin:install a plugin that defines some goals, let's say goalA and goalB. - verify that goalA and goalB can be attained - plugin:install a revised version of the same plugin that redefines goalA, does not define goalB, and defines a new goalC. - verify that goalA and goalC are attained properly, and goalA is the version from the revised plugin - verify that goalB no longer exists and cannot be attained. I often edit in-place in the plugin directory and copy back to the source directory when finished. But that's just me being lazy. I started out this way with beta7, but the new goal caching mechanism in beta8 seemed to defeat this approach for us. This seemed especially error-prone if you added or renamed goals in your live plugin.jelly. With beta8 we found it was better to get in the habit of using plugin:install to ensure consistent registration of the plugin's revised goals. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
