maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bentmann (JIRA)" <>
Subject [jira] Commented: (MSOURCES-25) Allow additional source directories to be configured
Date Sun, 28 Oct 2007 10:48:04 GMT


Benjamin Bentmann commented on MSOURCES-25:

bq. 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?

> Allow additional source directories to be configured
> ----------------------------------------------------
>                 Key: MSOURCES-25
>                 URL:
>             Project: Maven 2.x Source Plugin
>          Issue Type: New Feature
>    Affects Versions: 2.0.3
>            Reporter: Benjamin Bentmann
>            Priority: Minor
> 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:
> {code:xml}
> <sourceDirectories>
>   <sourceDirectory>src/main/java</sourceDirectory>
>   <sourceDirectory>src/main/javacc</sourceDirectory>
>   <sourceDirectory>src/main/jflex</sourceDirectory>
>   <sourceDirectory>src/main/uml</sourceDirectory>
> </sourceDirectories>
> {code}
> (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).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message