Mojo's AspectJ Maven Plugin
  1. Mojo's AspectJ Maven Plugin
  2. MASPECTJ-9

Add support for weaving classes in folders instead of jars

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.4
    • Labels:
      None
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      2

      Description

      Currently the plugin only supports adding jars to the ajc commandline parameter "-inpath". But "-inpath" supports folders with classes as well.

      The attached patch adds the new plugin option "weaveDirectories" to specify a list of folders with .class files to be added to the value for the "-inpath" parameter. A unit test and documentation is included as well.

      1. weavedirectories.patch
        14 kB
        Torsten Juergeleit
      2. weavedirectories.patch
        9 kB
        Torsten Juergeleit

        Activity

        Hide
        Torsten Juergeleit added a comment -

        To celebrate the first anniversary of this feature request I'm adding a description of our current use-case for this feature :-P

        We're using woven classes in our unit tests. To not create an additional Maven project for running the unit tests with the woven classes packaged in a jar we need this feature. This provides us with the possibility to weave class files created by the compiler plugin without packaging them into a jar first.

        To keep ajc from struggling with already woven classes we have to force the maven compiler plugin to create our (unweaved) classes in a separate directory via the command line option "-d" :

          <build>
              <plugins>
                  <plugin>
                      <artifactId>maven-compiler-plugin</artifactId>
                      <executions>
                          <execution>
                              <!-- Modifying output directory of default compile because non-weaved classes must be stored
                                   in separate folder to not confuse ajc by reweaving already woven classes (which leads to
                                   to ajc error message like "bad weaverState.Kind: -115") -->
                              <id>default-compile</id>
                              <configuration>
                                  <compilerArguments>
                                      <d>${project.build.directory}/unwoven-classes</d>
                                  </compilerArguments>
                              </configuration>
                          </execution>
                      </executions>
                    </plugin>
               </plugins>
           <build>
        

        To keep javac from bailing-out due to a non-existent directory "target/unwoven-classes/" we have to create this first. The following is a hack of (mis-) using the copy-resources goal of the Maven resource plugin for this:

        <build>
           <plugins>
              <plugin>
                <artifactId>maven-resources-plugin</artifactId>
                <executions>
                  <execution>
                    <phase>generate-sources</phase>
                    <goals>
                      <goal>copy-resources</goal>
                    </goals>
                    <configuration>
                      <outputDirectory>${project.build.directory}/unwoven-classes</outputDirectory>
                      <resources>
                      	<resource>
                      	    <directory>${basedir}</directory>
                      	    <includes>
                      	        <include>non-existent</include>
                            </includes>
                      	</resource>
                      </resources>
                    </configuration>
                  </execution>
                </executions>
              </plugin>
           </plugins>
        <build>
        

        By separating the unwoven classes from the woven ones we can add an additional check to trigger ajc only if javac created new unwoven classes.

        To weave the unwoven classes created by javac we're using the plugin option <weaveDirectories> introduced with the feature request:

            <build>
              <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>aspectj-maven-plugin</artifactId>
                        <configuration>
                            <weaveDirectories>
                                <weaveDirectory>${project.build.directory}/unwoven-classes</weaveDirectory>
                            </weaveDirectories>
                        </configuration>
                        <executions>
                            <execution>
                                <!-- Compile and weave aspects after all classes compiled by javac -->
                                <phase>process-classes</phase>
                                <goals>
                                    <goal>compile</goal>
                                </goals>
                            </execution>
                       </executions>
                   </plugin>
               </plugins>
           <build>
        
        Show
        Torsten Juergeleit added a comment - To celebrate the first anniversary of this feature request I'm adding a description of our current use-case for this feature :-P We're using woven classes in our unit tests. To not create an additional Maven project for running the unit tests with the woven classes packaged in a jar we need this feature. This provides us with the possibility to weave class files created by the compiler plugin without packaging them into a jar first. To keep ajc from struggling with already woven classes we have to force the maven compiler plugin to create our (unweaved) classes in a separate directory via the command line option "-d" : <build> <plugins> <plugin> <artifactId> maven-compiler-plugin </artifactId> <executions> <execution> <!-- Modifying output directory of default compile because non-weaved classes must be stored in separate folder to not confuse ajc by reweaving already woven classes (which leads to to ajc error message like "bad weaverState.Kind: -115" ) --> <id> default-compile </id> <configuration> <compilerArguments> <d> ${project.build.directory}/unwoven-classes </d> </compilerArguments> </configuration> </execution> </executions> </plugin> </plugins> <build> To keep javac from bailing-out due to a non-existent directory "target/unwoven-classes/" we have to create this first. The following is a hack of (mis-) using the copy-resources goal of the Maven resource plugin for this: <build> <plugins> <plugin> <artifactId> maven-resources-plugin </artifactId> <executions> <execution> <phase> generate-sources </phase> <goals> <goal> copy-resources </goal> </goals> <configuration> <outputDirectory> ${project.build.directory}/unwoven-classes </outputDirectory> <resources> <resource> <directory> ${basedir} </directory> <includes> <include> non-existent </include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin> </plugins> <build> By separating the unwoven classes from the woven ones we can add an additional check to trigger ajc only if javac created new unwoven classes. To weave the unwoven classes created by javac we're using the plugin option <weaveDirectories> introduced with the feature request: <build> <plugins> <plugin> <groupId> org.codehaus.mojo </groupId> <artifactId> aspectj-maven-plugin </artifactId> <configuration> <weaveDirectories> <weaveDirectory> ${project.build.directory}/unwoven-classes </weaveDirectory> </weaveDirectories> </configuration> <executions> <execution> <!-- Compile and weave aspects after all classes compiled by javac --> <phase> process-classes </phase> <goals> <goal> compile </goal> </goals> </execution> </executions> </plugin> </plugins> <build>
        Hide
        Dhanasekaran added a comment -

        any idea when will this feature be available with aspectj-maven-plugin?

        Show
        Dhanasekaran added a comment - any idea when will this feature be available with aspectj-maven-plugin?
        Hide
        Marvin Froeder added a comment -

        Or even if it will be included on aspectj

        Show
        Marvin Froeder added a comment - Or even if it will be included on aspectj
        Hide
        Ryan Rich added a comment -

        I have a use case where I could use this as well... doing WAR overlays on some vendor provided WAR files via the maven war plugin. In addition to standard file overlays we have found the need to apply some aspects to their classes. We can't use a .war file as a weaveDependency so it would be useful to allow a directory location to be specified that is part of the inpath (which would allow us to extract the classes to the location prior to weaving).

        I agree that most of these use cases are pretty non-standard, but it is basic functionality that ajc and AJDT provides so why not expose it?

        Show
        Ryan Rich added a comment - I have a use case where I could use this as well... doing WAR overlays on some vendor provided WAR files via the maven war plugin. In addition to standard file overlays we have found the need to apply some aspects to their classes. We can't use a .war file as a weaveDependency so it would be useful to allow a directory location to be specified that is part of the inpath (which would allow us to extract the classes to the location prior to weaving). I agree that most of these use cases are pretty non-standard, but it is basic functionality that ajc and AJDT provides so why not expose it?
        Hide
        Robert Scholte added a comment -

        Somehow it took 1040 days to apply this patch.
        It's an old patch, so I had to adjust it here and there.
        With this feature I think I can close some other issues too.
        This feature will require some more code, like there should be an option to (un)set the sourcespaths (related to MASPECTJ-95), make them optional (related to MASPECTJ-99).
        At least the AspectJ option is now exposed.

        Fixed in rev.4243

        Show
        Robert Scholte added a comment - Somehow it took 1040 days to apply this patch. It's an old patch, so I had to adjust it here and there. With this feature I think I can close some other issues too. This feature will require some more code, like there should be an option to (un)set the sourcespaths (related to MASPECTJ-95 ), make them optional (related to MASPECTJ-99 ). At least the AspectJ option is now exposed. Fixed in rev.4243

          People

          • Assignee:
            Robert Scholte
            Reporter:
            Torsten Juergeleit
          • Votes:
            9 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: