[
http://jira.codehaus.org/browse/MSOURCES-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111743
]
Benjamin Bentmann commented on MSOURCES-25:
-------------------------------------------
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.
> Allow additional source directories to be configured
> ----------------------------------------------------
>
> Key: MSOURCES-25
> URL: http://jira.codehaus.org/browse/MSOURCES-25
> 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:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
