Re: Best practices for java version?
Dirk Olmes a écrit : delbd wrote: Dirk Olmes a écrit : Graham Leggett wrote: Richard Chamberlain wrote: I agree it's not ideal, but I'm open to suggestions as to how to guarantee code from a particular project works in a java 1.4 environment? Use Continuous Integration and a test suite. That's what we do here, too. We use profiles that are auto-activated by the JDK type and have modules declarations only inside the profiles. WE evaluated going through the hassle of specifying the RT jar etc but in the end decided that it wouldn't be worthwhile so we just use -source and -target to bulid. Our CI server has two build plans: one for regular JDK5 builds (that runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4 source compatability for the modules that require it. Even greater care must be taken now when managing the dependecies: does any module bring in JDK5 compatible third party deps in? Do JDK14 modules depend on JDK5 modules? Cross-JDK builds are doable with Maven, is's just another pile of complexity on top of what you're already having to deal with. So, can we consider that a successfull build using a 1.4 JDK + "source" and "target" in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? Not really. After a successful build with JDK1.4 you know that none of your direct dependencies (the ones you're importing in your Java classes) don't use JDK5. At runtime this may be a completely different story as transitive dependencies on which you don't have compile time dependencies might still be JDK5. You *might* be safe once all your tests run green on JDK1.4 as well but that requires proper coverage, of course. Yeah, that's what i thought. So we can consider that maven is missing one important thing in dependency management: the jvm dependency. I think it should be possible for a dependency to specify that it aims a specific jvm and as such if a project aims a lower dependency, you'll have a conflict that would appear in report (there is already such report for regular dependencies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
Dirk Olmes a écrit : Graham Leggett wrote: Richard Chamberlain wrote: I agree it's not ideal, but I'm open to suggestions as to how to guarantee code from a particular project works in a java 1.4 environment? Use Continuous Integration and a test suite. That's what we do here, too. We use profiles that are auto-activated by the JDK type and have modules declarations only inside the profiles. WE evaluated going through the hassle of specifying the RT jar etc but in the end decided that it wouldn't be worthwhile so we just use -source and -target to bulid. Our CI server has two build plans: one for regular JDK5 builds (that runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4 source compatability for the modules that require it. Even greater care must be taken now when managing the dependecies: does any module bring in JDK5 compatible third party deps in? Do JDK14 modules depend on JDK5 modules? Cross-JDK builds are doable with Maven, is's just another pile of complexity on top of what you're already having to deal with. -dirk So, can we consider that a successfull build using a 1.4 JDK + "source" and "target" in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? David Delbecq - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven tests grr argh!
keteracel a écrit :
Hi All,
I'm trying to move a big decrepit ant build over to maven but have hit a bit
of a stumbling block with running the tests. We have a standard directory
structure with some tests in src/test/java but we also have a large number
of the tests (~2000) in public-static-classes of the class they test in
src/main/java, e.g.:
public class SimpleClass {
public int returnOne {
return 1;
}
public static class Test extends junit.framework.TestCase {
public void testReturnOne() {
assertEquals(1, new SimpleClass().returnOne());
}
}
}
If I run mvn test, it only picks up the tests in the test directory and not
the tests in the src directory. If I set the testDirectory in the build
section of my pom to the src/main/java/ directory mvn test then picks up
these tests but not those in the src/test/java/ directory.
There are good reasons why some of the tests should be within the file they
are testing (testing of private methods) so I can't rip them all out. So, my
question is:
How can I make maven run all tests in both the src/main/java/ and
src/main/test/ directories?
Thanks,
Paul.
No need to grr Argh in mail subject, won't make people answer you faster :)
To add additional sources folder to your test, use the
build-helper-maven-plugin:add-test-source goal.
http://mojo.codehaus.org/build-helper-maven-plugin/usage.html
Regards,
David Delbecq
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mvn release on sourceforge release system
Hello, i found out this old maven1 plugin http://maven-plugins.sourceforge.net/maven-sourceforge-plugin/index.html which makes it possible to deploy maven artefacts to sourceforge releases system. Is it possible to do the same with maven2? Afaik, maven 2 uses wagon to makes all it's file transfert (be it over ftp, dav, scp, etc). So i suppose i would need a wagon plugin for sourceforge releases. Does such plugin / wagon provider already exist? Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: converting from maven1 to maven2, pom for third party jars?
the deploy target doesnt seem to accept the fact our local repository requires password authentification. it just fails. Our server ask client for credential for write operation (apache DAV mod) but maven doesn't try with password. i'll give a try using install:install-file thanks [EMAIL PROTECTED] a écrit : There is a solution for this problem. The deploy:deploy-file will automatically generate a pom file. So, remove the jars from your remote repository and deploy them again with mvn deploy:deploy-file . Perhaps if you make a list with the directories it should be possible to create a little script to do it. Hth, Nick S. -Original Message- From: David Delbecq [mailto:[EMAIL PROTECTED] Sent: Wed 3/5/2008 16:27 To: Maven Users List Subject: converting from maven1 to maven2, pom for third party jars? Hello, in the process of converting our app from maven1 to maven2, we changed our repository to have maven2 structure. For most library we use public repositories (maven, jboss, apache) to fetch files. But from some libraries we had to make them available to our local repository, moving the jar from his group/jars/artefact-version.jar to group/artifact/version/artifact-version.jar. However, for the jar there is no "pom" files coming along, just a jar. maven2 has no special trouble handling them, except it keeps trying to go to all our configured repositories and try to download those inexistant pom: Downloading: http://xxx/repository/enhydra/dods/dbmanager-api/6.4-1/dbmanager-api-6.4-1.pom Downloading: http://download.java.net/maven/2//enhydra/dods/dbmanager-api/6.4-1/dbmanager-api-6.4-1.pom Downloading: http://archiva.openqa.org/repository/releases//enhydra/dods/dbmanager-api/6.4-1/dbmanager-api-6.4-1.pom Downloading: http://repository.jboss.com/maven2/enhydra/dods/dbmanager-api/6.4-1/dbmanager-api-6.4-1.pom Downloading: http://repo1.maven.org/maven2/enhydra/dods/dbmanager-api/6.4-1/dbmanager-api-6.4-1.pom Downloading: http://xxx/repository/enhydra/dods/stdconnection/6.4-1/stdconnection-6.4-1.pom Downloading: http://download.java.net/maven/2//enhydra/dods/stdconnection/6.4-1/stdconnection-6.4-1.pom Downloading: http://archiva.openqa.org/repository/releases//enhydra/dods/stdconnection/6.4-1/stdconnection-6.4-1.pom Downloading: http://repository.jboss.com/maven2/enhydra/dods/stdconnection/6.4-1/stdconnection-6.4-1.pom Downloading: http://repo1.maven.org/maven2/enhydra/dods/stdconnection/6.4-1/stdconnection-6.4-1.pom Downloading: http://xxx/repository/enhydra/dods/ejen/6.4-1/ejen-6.4-1.pom Downloading: http://download.java.net/maven/2//enhydra/dods/ejen/6.4-1/ejen-6.4-1.pom Downloading: http://archiva.openqa.org/repository/releases//enhydra/dods/ejen/6.4-1/ejen-6.4-1.pom Downloading: http://repository.jboss.com/maven2/enhydra/dods/ejen/6.4-1/ejen-6.4-1.pom Downloading: http://repo1.maven.org/maven2/enhydra/dods/ejen/6.4-1/ejen-6.4-1.pom As you see, it tries to go to 5 different repositories, everytime to get a 404. Is there a recommended way to either a) tell maven that there is definitely no pom to download b) create the pom and metadata file from a .jar file (generic pom with correct names, but no dependencies)? I tried for some jar to manually create pom, i received complains about checksums ? and maven ignored the file! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
