0

I have a library which is used via inline taglets. It's intended to be used by other libraries, for inserting example code into their JavaDoc.

The library is done, and, hallelujah, as of yesterday, it's now on Maven Central.

I'm now implementing this library into another project for the first time. That project compiles its code with java.version 1.5. But the taglet library requires 1.7. Not just for running javadoc.exe, but also for compiling optional "taglet customizer" classes.


UPDATE: These customizer classes are created by each developer--the person using the taglet library in their library. The customizer classes (which are completely optional--they're needed only for advanced features, and you can get away with creating none) are required to be compiled before executing javadoc.exe.


So it needs the following goals:

  1. Compile the main library classes (requires Java 1.5) (mvn compile)
  2. Compile the customizers (requires Java 1.7) (mvn compilecodelet?)
  3. Run javadoc.exe (Java 1.7) (`mvn docs'?)

mvn install would therefore call these three goals in order.

I'm new to Maven, and would appreciate some advice on how to do this. This is what I've found out so far:

Here's the project's current compile goal:

<properties>
    <java.version>1.5</java.version>
</properties>

<plugin>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.3.2</version>
   <configuration>
      <encoding>UTF-8</encoding>
      <source>${java.version}</source>
      <target>${java.version}</target>
   </configuration>
</plugin>

It seems the JDK for this project should be upgraded to 1.7, with the main classes compiled with the <source> and <target> flags set to 1.5, and the taglet-customizers compiled with those flags set to 1.7.

Some references:


How can I set up this extra compilecodelet goal, and set the whole project up so it can handle both JDK versions? And so that mvn install (and whatever other "master" goals) also call this new sub-goal in the proper sequence?

As I said, I'm new to Maven, and although I'm starting to understand bits and pieces, but I don't know how to put this all together yet.

Thank you for helping.

aliteralmind
  • 19,847
  • 17
  • 77
  • 108
  • It sounds that you are going the wrong way cause this taglet as far as i understand should be used within JavaDoc so you have to go via [maven-javadoc-plugin](http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#taglet). – khmarbaise Jul 25 '14 at 17:57
  • It's executed via JavaDoc, that's true. But it's optional "customizer" classes must be compiled first, before running JavaDoc/the library's taglets. This compilation requires 1.7. But the library itself requires 1.5. – aliteralmind Jul 25 '14 at 17:59
  • So you should make taglet lib (jar file) and just use it as dependency for mavan-javadoc-plugin. Apart from that if the library requires 1.5 it should run with Java 1.7. So i don't see problem. – khmarbaise Jul 25 '14 at 18:07
  • I'm not being clear. Each library's developer, who wants to use Codelet (the taglet library) in *their* library, will be creating these customizer classes. They are for customizing the output of *their* specific example codes (they're optional...they're only needed when you want to use [advanced features](http://aliteralmind.com/docs/computer/programming/codelet/documentation/javadoc/overview-summary.html#xmpl_links)--and just FYI: you can get by without creating any customizers). The customizer classes must be compiled before `javadoc.exe` is executed. – aliteralmind Jul 25 '14 at 18:21
  • This particular library, my friend's library that I'm implementing Codelet into, requires it's main code to be compiled to 1.5 source. Customizers must be compiled to 1.7. And JavaDoc must also be run with JDK 1.7. – aliteralmind Jul 25 '14 at 18:22
  • 1
    Oracle no longer supports 1.5, so why should you? Tell the client to get with the program and upgrade. – Software Engineer Jul 25 '14 at 18:37
  • @EngineerDollery Should a widely-used library do that it to its users so suddenly? Seems like they should have a few sub-versions of warning before being forced to upgrade their JVM. – aliteralmind Jul 25 '14 at 18:41
  • Anyway, it's not my library. I can certainly suggest he upgrade it, but I'm dealing with what I've got. – aliteralmind Jul 25 '14 at 20:42

1 Answers1

1

I share the misgivings of the others who commented on your question, doing what you ask seems risky and error-prone to me. It might be better to put the codelet extension classes in a separate project, build them with source & target of 1.7, and add a dependency on the codelet extension jar in the library POM's javadoc plugin configuration.

However if that is not possible, I would try something like this. It is untested but should give you the idea.

Assuming this directory structure:

basedir
  src
    main
      java
         regularLibCodePackage
         codeletExtensionPackage

<properties>
  <java.version>1.5</java.version>
  <!-- sets encoding for the whole Maven build -->
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>2.3.2</version>  <!--consider using latest plugin version -->
  <configuration>
    <!-- applies to all executions unless overridden by an execution -->
    <source>${java.version}</source>
    <target>${java.version}</target>
  </configuration>
  <executions>
    <execution>
      <id>default-compile</id>
      <configuration>
        <excludes>
          <!-- Not sure exactly what the path should be here, the docs aren't 
               clear. Maybe it should be an absolute path, e.g. 
               ${project.basedir}/src/main/java/codeletExtensionPackage?
               When you figure it out let me know and I'll edit the response. -->
          <exclude>codeletExtensionPackage</exclude>
        </excludes>
      </configuration>
    </execution>
    <execution>
      <id>codelet-compile</id>
      <phase>compile</phase>
      <goals>
        <goal>compile</goal>
      </goals>
      <configuration>
        <source>1.7</source>
        <target>1.7</target>
        <excludes>
          <!-- See note above about what to put here -->
          <exclude>regularLibCodePackage</exclude>
        </excludes>
      </configuration>
    </execution>
  </executions>
</plugin>

Do you need to keep the 1.7 classes out of the final jar? In other words, are the additional classes just required for running the Javadoc plugin? If the answer is 'yes' then you will also need to adjust the default jar plugin execution. (And if the answer is yes, this is another reason to put the codelet classes in a separate project!)

<plugin>
  <artifactId>maven-jar-plugin</artifactId>
  <version>2.5</version>  <!--consider using latest plugin version -->
  <executions>
    <execution>
      <id>default-jar</id>
      <configuration>
        <excludes>
          <exclude>codeletExtensionPackage</exclude>
        </excludes>
      </configuration>
    </execution>
  </executions>
</plugin>

I used excludes in the compiler and jar plugin configs, there is a companion includes block as well. I leave it to you to figure out the working config, this should get you started.

user944849
  • 14,524
  • 2
  • 61
  • 83
  • It seems then, that my question is an [XY problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). I'm going to post a new question that I think gets to the root of the problem, without being stuck on this multi-version compilation being the supposed solution. As I mentioned, I'm new to Maven. I think the way I've designed my project, in as far as where and how these customizer functions (functions really, not necessarily classes) are to be created, may need to change. To answer your question, customizer functions are only needed by JavaDoc. Thank you for your insight. – aliteralmind Jul 25 '14 at 23:17