File name encoding at mvn deploy?
Hello, I have a small problem with Maven (2.2.0) deploying to Nexus (1.3.5). I am evaluating Maven + freehep-nar-plugin (1) to build native projects. The plugin adds additional .nar files to the deployment of my Maven module. Some of these files contain platform specific information in the file name. As an example, the build under 32bit Linux with the GNU toolchain results in the file: utilities-0.4.0-SNAPSHOT-i386-Linux-g++-static.nar in my local repository. However, if I run mvn deploy to push these files to our corporate Nexus repository, the "+"-characters get encoded and the file ends up in the repository as: utilities-0.4.0-SNAPSHOT-i386-Linux-g%2B%2B-static.nar Can I configure Maven to not encode this? Should I rather configure this in Nexus? Or is this a bug? Greetz, Ringo (1) http://java.freehep.org/freehep-nar-plugin/intro.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-release-plugin: branch goal does not take same properties as prepare goal
Hello, I am trying to automate the branching for a few hundred Maven projects. The automation of creating a release works great using the -DreleaseVersion and -DdevelopmentVersion properties using the prepare goal. The documentation of the branch goals states this: "The branch goal can use the same properties used by the prepare goal for specifying the versions to be used." It seems that I can't use the version properties from the release goal, but that I should specify these: project.[rel|dev].org.myCompany:projectA However, these properties contain project specific information, which means that I can't use the multi-module approach to automate the branching for all my projects at once. Our versioning strategy always takes the same major/minor number and branch name for modules going together in a release. Am I missing something? Any hints on how to get around this? Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Aren't ranges allowed when releasing?
Chris, > 2009/3/19 > >> I'm trying to release a project, that has these dependencies in it. It >> works fine for install/package etc, but only when releasing does it >> complain. >> >> If it can choose the correct one to compile and package against, why can we >> not trust it to choose it when releasing? >> [INFO] Can't release project due to non released dependencies : >> com.ibm.sct.common:Foundation:jar:[3.0.0.0,4.0.0.0):provided >> com.ibm.sct.common:MIL:jar:[3.0.0.0,4.0.0.0):provided >> com.ibm.sct.common:TelstraCustom:jar:[3.0.0.0,4.0.0.0):provided >> in project 'BatchDataServices' >> (com.ibm.sct.common:BatchDataServices:jar:3.0.0.1-SNAPSHOT) >> [INFO] >> >> [INFO] For more information, run Maven with the -e switch Do you have releases of all the dependent modules with version number 3.0.0.0 ? I suspect not! Second, your version ranges are defined very strictly. Maven has a convention for 3 part build numbers: major.minor.build. If you want to specify the latest release within the same release (e.g. 2.5), then specify your range as: [2.5,2.6) This will match a release 2.5.x with x the highest number available from your Maven repository. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Checking the java class version in maven artifacts
Brett,
2009/3/21 Brett Randall :
> I think this was asked on the list last week, or recently anyway. The
> poster was pointed at https://animal-sniffer.dev.java.net/ .
You are right! I requested this last week. However, the Maven plugin
of animal-sniffer didn't really have a mojo for only checking the
class file versions although most of the ground work was there. I sent
Koshuke a patch for including another goal to check the main and
attached artifacts for a specific Java version. It seems it can help
out some other people too, so here is the patch file again.
Ringo
diff --git
a/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/ClassFileVisitor.java
b/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/ClassFileVisitor.java
index b814c9a..2ae98b4 100644
---
a/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/ClassFileVisitor.java
+++
b/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/ClassFileVisitor.java
@@ -35,7 +35,7 @@ public abstract class ClassFileVisitor {
if(file.getName().endsWith(".class"))
processClassFile(file);
else
-if(file.getName().endsWith(".jar"))
+if(file.getName().endsWith(".jar") || file.getName().endsWith(".war"))
processJarFile(file);
// ignore other files
diff --git
a/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/maven/ClassVersionMojo.java
b/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/maven/ClassVersionMojo.java
new file mode 100644
index 000..28c41b9
--- /dev/null
+++
b/animal-sniffer/src/main/java/org/jvnet/animal_sniffer/maven/ClassVersionMojo.java
@@ -0,0 +1,86 @@
+package org.jvnet.animal_sniffer.maven;
+
+import java.io.File;
+import java.io.IOException;
+import java.util.*;
+
+import org.apache.maven.plugin.AbstractMojo;
+import org.apache.maven.plugin.MojoExecutionException;
+import org.apache.maven.plugin.MojoFailureException;
+import org.apache.maven.project.MavenProject;
+
+/**
+ * Checks that all the built JAR/EAR/WAR files contain class files targeted to
a specific
+ * Java version.
+ *
+ * @author Ringo De Smet
+ * @phase verify
+ * @goal classVersions
+ */
+public class ClassVersionMojo extends AbstractMojo {
+
+ private final static Map JAVA_VERSIONS_MAP;
+
+ static {
+ JAVA_VERSIONS_MAP = new HashMap();
+ JAVA_VERSIONS_MAP.put("1.3", new Integer(47));
+ JAVA_VERSIONS_MAP.put("1.4", new Integer(48));
+ JAVA_VERSIONS_MAP.put("5.0", new Integer(49));
+ JAVA_VERSIONS_MAP.put("6.0", new Integer(50));
+ }
+
+ /**
+* @parameter expression="${project}"
+* @required
+* @readonly
+*/
+ private MavenProject project;
+
+ /**
+* Specify the Java version where all class files should comply to.
+* Valid values for this argument are '1.3', '1.4', '5.0' and '6.0'.
+*
+* @parameter expression=${javaVersion} default="1.4"
+*/
+ private String javaVersion;
+
+ /**
+* Specify whether the built artifacts should have generated class files
+* exactly for the specified Java version. By default, this is not enforced.
+* If it is enforced, even class file versions for a lower JDK version are
not
+* allowed. For instance, when the javaVersion specified is '5.0' and this
+* parameter is set to 'true', then class files for Java 1.4 are not
allowed either.
+*
+* @parameter expression="${strict}" default="false"
+*/
+ private boolean strict;
+
+ public void execute() throws MojoExecutionException, MojoFailureException {
+ Integer requestedClassVersion =
(Integer)JAVA_VERSIONS_MAP.get(javaVersion);
+ if(requestedClassVersion==null) {
+ throw new MojoFailureException("Invalid Java version '" + javaVersion
+ "'! Valid values are 1.3, 1.4, 5.0 and 6.0.");
+ }
+ ReportingClassFileVersionVisitor visitor = new
ReportingClassFileVersionVisitor(getLog(),requestedClassVersion.intValue(),strict);
+ List builtArtifacts = new ArrayList();
+ // Add the main artifact
+ builtArtifacts.add(project.getArtifact());
+ // Add additional attached artifacts
+ builtArtifacts.addAll(project.getAttachedArtifacts());
+ if(getLog().isDebugEnabled())
+ getLog().debug("Validating class files to match version number " +
requestedClassVersion);
+ for(int artifactNumber = 0; artifactNumber < builtArtifacts.size();
artifactNumber++) {
+ org.apache.maven.artifact.Artifact artifact =
(org.apache.maven.artifact.Artifact) builtArtifacts.get(artifactNumber);
+ try {
+File artifactFile = artifact.getFile();
+getLog().info("Checking class file versions of " +
artifactFile.getName());
+visitor.process(artifactFile);
+
Re: Plugin to validate the class file version of built artifacts?
2009/3/17 Stephen Connolly : > google this "animal sniffer Kohsuke" > > it should give you what you're after Thanks Stephen, this was what I was looking for! For the email archives: http://animal-sniffer.dev.java.net Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges
2009/3/11 Johannes Schneider : > There is a dependency to Jide defined: > > [2.2.0, 3.0.0) > > Could anyone give me a hint how to solve this? Drop the build number from your starting version, only leaving the major and minor part: [2.2, 3.0.0) Leaving the build number out of your version specification can be interpreted as : [2.2.*, 3.0.0) Hope this helps. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugin to validate the class file version of built artifacts?
Dirk, 2009/3/17 Dirk Olmes : > > Can't you just configure a JDK1.4 in hudson to use for compiling/running > Maven on the jobs that build your project? The tight Maven2 build support in Hudson, including the Maven module dependency support, requires that your Maven runs in Java 1.5 unfortunately. I can run the Maven jobs as free-style jobs, but then I loose the build order based on the Maven dependencies. I'm not gonna configure this manually for 346 Maven modules. :-) Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugin to validate the class file version of built artifacts?
Gabriele, 2009/3/17 Gabriele Columbro : > Maybe you're referring to the maven-enforcer-plugin? [1] > > I've never used personally so not sure if it can accomplish your goal, but > hopefully can help ;) > Nope, that's not the one. This one check that you are running under a specific JVM version. I can't use this one because our developers are on a real Java 1.4 environment, and on Hudson I'm running in a Java 1.5 environment. Although I used Maven profiles to my advantage for the different running environments (e.g. configuring the maven compiler plugin differently), I want to 100% sure that all class files generated by *any* plugin are Java 1.4 class files. This plugin should be one that runs at the end of a build and really scans the jar/war/ear files, not the classes folder. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to use maven-release-plugin to build/release from a branch?
Eric, 2009/3/16 Eric B. : > Hi, > > How can I use the release:perform goal in the maven-release-plugin to build > my module located in a CVS branch? > > I have tried mvn release:perform -DtagBase=B_2_0_0 hoping / expect that it > would pass the tagBase command along to CVS to checkout the sources from > that tag. Unfortunately, it doesn't: > >From the maven-release-plugin docs, I deduce that tagBase is only used when your SCM is Subversion. I have never had any problems so far with making a release on a CVS branch. How did you create the tag? You ran mvn release:prepare right? If you ran it and it is successfull, you should be able to just run mvn release:perform without any further arguments. The release plugin should pickup all the required release information from the file release.properties created by the prepare step. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-scm-plugin define -Dmaven.scm.provider.cvs.implementation in pom?
2009/3/16 Eric B. : > > I've been trying to figure out if there is a way to specify the > maven.scm.provider.cvs.implementation in the pom or in a profile, but > haven't been able to find anything. I know I can > specify -Dmaven.scm.provider.cvs.implementation=cvs_native on the command > line, but would like to do it from the pom. > > I did find http://jira.codehaus.org/browse/SCM-303, but I am running scm > 2.0-beta-8 and I still cant seem to get it to work. I can only confirm that it doesn't work for me either. I tried it with putting the property in an always active profile in my settings.xml. I am running Maven 2.0.9 on Windows 2000SP4 Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Plugin to validate the class file version of built artifacts?
Hello, Our current build system is based on JDK 1.4.2 and Maven 2.0.9. We are in the process of migrating from Continuum to Hudson. Hudson requires Java 1.5 for its Maven2 integration. I already updated the configuration of some of the plugins to make sure that 1.4 compatible bytecode is generated. Before I can really make the switch, I would like to be sure that my JAR files only contain Java 1.4 class files (class file version 48.0). Is anyone aware of a Maven plugin that I can run somewhere near the end of my build which checks the class file version of all classes in my built jar/war/ear files? I have the impression of someone mentioning such support, but I can't find it anymore (Google, mailing list archives) Thanks, Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-compiler-plugin - where does it take compiler from?
2009/3/13 Nick Stolwijk : > It will use the build-in compiler in your JDK you are using to run > Maven. So just make sure every developer uses the right JDK version. And if you want to enforce it, use the maven-enforcer-plugin to make sure builds only take place in the correct JDK version: http://maven.apache.org/plugins/maven-enforcer-plugin/ Look for requireJavaVersion in the docs. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: scm:update pom.xml to latest version on branch when checked out by tag
2009/2/18 Mark Struberg : > what do you mean with: >> tag one of your projects with "code_to_include_in_release" > ? > you surely mean the tag which will automatically be created via > realease:prepare, don't you? No. Read my first mail: developers tag the code that they want to go into a release. This means I want to create a release out of the tagged code, which is not always the latest on the branch. > mvn release:perform should work on such a tag without writing things back to > the repo (at least this was the status the last time I looked at the release > sources a good time ago). Oops, I meant release:prepare, not release:perform. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: scm:update pom.xml to latest version on branch when checked out by tag
Mark, 2009/2/18 Mark Struberg : > maybe I did not understand what you really like to do, but did you look at > release:rollback? This will revert the pom back to the original status. > > One for sure: the scm providers won't help you much when it comes to > manipulating the pom.xml. They are strictly for scm handling only. Not what I had in mind. :-) As an example, tag one of your projects with "code_to_include_in_release". Do a checkout of the project based on that tag and try to run release:perform. You will see what blocks me in creating a release: the release-plugin can't commit the rewritten pom.xml since it was checked out using a sticky tag. My idea of a solution was to update pom.xml to the latest version on the branch (so the sticky tag is removed) before running release:perform. Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
scm:update pom.xml to latest version on branch when checked out by tag
Hello, This is actually a repost of this message: http://markmail.org/message/2xzsgvxmln5krgdl However, no answers came and I didn't find a solution yet. I check out a project based on a floating tag in CVS. The tag indicates the code that can go in a release. Before the release plugin can update pom.xml correctly, I need to update the file to latest revision on the underlying branch to get rid of the sticky tag. I know the CVS command line to do it, but can it be done via the maven-scm-plugin? Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
