Maven 2.x Source Plugin

Allow additional source directories to be configured

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.0.3
  • Fix Version/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Currently, the plugin simply archives the compile source roots and resource directories that are known to the POM. However, there may exist further files which do not directly contribute to the build process but are nevertheless to be considered as "source" files.

For example, consider a project with the following directories:

  • src/main/java
  • src/main/javacc
  • src/main/jflex
  • src/main/uml

The directories "javacc" and "jflex" provide grammar definitions for generated java files while "uml" contains UML (or similar) models from which MDA tools create java files. I would consider it useful to package these "pre-source" files as well into the sources JAR.

Surely, the assembly-plugin would do the job but since it requires quite a complete build I consider this approach quite unattractive when I want to package up files that are already hanging around in the file system.

While adding more directory roots to the archive is in principle no big deal for the source-plugin, the major question would be how to nicely configure the plugin to do so. My spontaneous proposal would be an additional configuration parameter "sourceDirectories" of type File[] with the following semantic:
If not specified (as would be the case for all currently existing configurations), simply package compile source roots and resources from POM like it does now. If I understand mojo configuration correctly, the mojo parameter would be null in this case.
Otherwise (i.e. if POM configuration contains <sourceDirectories> element), ONLY those directories listed up here should be packaged. This would allow precise control what the plugin packages. For example, if one does not want to package resources, simply omit to list up their root directory. For my formerly mentioned example, one would need to write:

<sourceDirectories>
  <sourceDirectory>src/main/java</sourceDirectory>
  <sourceDirectory>src/main/javacc</sourceDirectory>
  <sourceDirectory>src/main/jflex</sourceDirectory>
  <sourceDirectory>src/main/uml</sourceDirectory>
</sourceDirectories>

(BTW, not sure whether Plexus can actually handle the non-standard plural form ending with "ies").

Of course, things are not that simple... The above illustrated approach conflicts with the current solution for MSOURCES-22. Furthermore, the plugin is currently aware of includes/excludes for the resources being packaged. This cannot be realized by a simple configuration parameter of type File[], i.e. <sourceDirectory>src/main/resources</sourceDirectory> would not be equivalent to the default behavior, causing confusion. Therefore, one might need something like a SourceDirectory bean that holds the directory path and optional includes/excludes (similar to an Ant fileset).

Issue Links

relates to

New Feature - A new feature of the product, which has yet to be developed. MSOURCES-38 Add zip goal to create a source zip containing all sources

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

Surely, the assembly-plugin would do the job but since it requires quite a complete build I consider this approach quite unattractive

Note quite sure, but maybe my use-case would be better adressed by another mojo for the assembly-plugin: A new mojo named "source-assembly" that does not require @execute phase="package" but something less expensive like the source-plugin should do equally fine.

This thought gives rise to the question whether one could totally abandon the source-plugin by mapping all use-cases of it to predefined assembly descriptors, allowing to concentrate development on a single plugin?

Show
Benjamin Bentmann added a comment - Surely, the assembly-plugin would do the job but since it requires quite a complete build I consider this approach quite unattractive Note quite sure, but maybe my use-case would be better adressed by another mojo for the assembly-plugin: A new mojo named "source-assembly" that does not require @execute phase="package" but something less expensive like the source-plugin should do equally fine. This thought gives rise to the question whether one could totally abandon the source-plugin by mapping all use-cases of it to predefined assembly descriptors, allowing to concentrate development on a single plugin?
Hide
Permalink
Dennis Lundberg added a comment -

There are two predefined assemblies available in the assembly plugin, that can do what you want. They do not require much configuration to use. Please see the src and project descriptorIds on this page:

http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html

Show
Dennis Lundberg added a comment - There are two predefined assemblies available in the assembly plugin, that can do what you want. They do not require much configuration to use. Please see the src and project descriptorIds on this page: http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html
Hide
Permalink
Benjamin Bentmann added a comment -

Well, I know of these predefined descriptors for the assembly plugin. I have no problems with defining my own descriptors, too. My request was more directed towards a inexpensive solution in terms of execution time, e.g. I would have liked to execute something as simple as "mvn source:jar" that gets the files quickly packaged. Running the assembly plugin from the command line runs the "package" phase that may take some time for a non-Hello-World-Project ...

In plain english: Yes, what I request is in principle already possible so I do not mind if you just close this issues as "Won't fix". The question was just, could it be more comfortable (isn't convenience one reason why build tools were invented ). I mean, the code to produce an archive from multiple root directories with includes/excludes is already there (in both plugins), there is just no user-interface to use this for the use-case sketched above, what I consider quite pity.

Show
Benjamin Bentmann added a comment - Well, I know of these predefined descriptors for the assembly plugin. I have no problems with defining my own descriptors, too. My request was more directed towards a inexpensive solution in terms of execution time, e.g. I would have liked to execute something as simple as "mvn source:jar" that gets the files quickly packaged. Running the assembly plugin from the command line runs the "package" phase that may take some time for a non-Hello-World-Project ... In plain english: Yes, what I request is in principle already possible so I do not mind if you just close this issues as "Won't fix". The question was just, could it be more comfortable (isn't convenience one reason why build tools were invented ). I mean, the code to produce an archive from multiple root directories with includes/excludes is already there (in both plugins), there is just no user-interface to use this for the use-case sketched above, what I consider quite pity.
Hide
Permalink
Milos Kleint added a comment -

the sources plugin should definitely allow to package Scala and Groovy files in the -sources.jar. (src/main/groovy and src/main/scala), as one of the primary reason for it to exist is the IDE support (debugging/completion/documentation).

Show
Milos Kleint added a comment - the sources plugin should definitely allow to package Scala and Groovy files in the -sources.jar. (src/main/groovy and src/main/scala), as one of the primary reason for it to exist is the IDE support (debugging/completion/documentation).
Hide
Permalink
Milos Kleint added a comment -

let's see, what about me adding an additionalSourceRoots/additionalSourceRoot configuration that would default to src/main/groovy+src/main/scala and if these folders exists (which are the default folders for the respective languages unfortunately no way to obtain the actual configuration in the given project) add the content to the sources jar?

Show
Milos Kleint added a comment - let's see, what about me adding an additionalSourceRoots/additionalSourceRoot configuration that would default to src/main/groovy+src/main/scala and if these folders exists (which are the default folders for the respective languages unfortunately no way to obtain the actual configuration in the given project) add the content to the sources jar?
Hide
Permalink
Milos Kleint added a comment -

the only problem seems to be aggregate goal which is not capable of retrieving the configuration from the reactor projects..

Show
Milos Kleint added a comment - the only problem seems to be aggregate goal which is not capable of retrieving the configuration from the reactor projects..
Hide
Permalink
Bob Fields added a comment -

Adding additional source or resource roots does not solve the problem of not wanting to include additional elements in the project runtime artifact. I'm still trying to figure out the usefulness of the 'includes' configuration item if you can only accomplish this with additional resources or sources directories. It seems like we could simply add that configured reference to the included directories (either absolute or relative location) and use those when building the source artifact from source:jar. In our case, we have UML artifacts and xsd artifacts used to generate code plus Eclipse project configurastion, which we don't want included as project resources, and we don't want to have to go through all of the lifecycle steps when creating the sources jar.

Show
Bob Fields added a comment - Adding additional source or resource roots does not solve the problem of not wanting to include additional elements in the project runtime artifact. I'm still trying to figure out the usefulness of the 'includes' configuration item if you can only accomplish this with additional resources or sources directories. It seems like we could simply add that configured reference to the included directories (either absolute or relative location) and use those when building the source artifact from source:jar. In our case, we have UML artifacts and xsd artifacts used to generate code plus Eclipse project configurastion, which we don't want included as project resources, and we don't want to have to go through all of the lifecycle steps when creating the sources jar.

People

  • Assignee:
    Milos Kleint
    Reporter:
    Benjamin Bentmann
Vote (8)
Watch (1)

Dates

  • Created:
    Updated: