You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/07/26 06:13:57 UTC
[jira] Updated: (MNG-643) Support and for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=all ]
Brett Porter updated MNG-643:
-----------------------------
Priority: Major (was: Blocker)
Fix Version: 2.0-beta-2
Component: (was: maven-model)
maven-plugins
I'm all for including this, but let's just expose it as parameters of the compiler mojo. Reasons:
1) that's fine, but it's not project metadata
2) that's bad, we should not support it in the metadata. For example, it won't map to an IDEA project
3) belongs in that particular plugin's configuration, its not project metadata
4, 5) I don't understand your points on these ones, sorry
I'm -1 to the pom format mentioned above:
- would rather not introduce metadata for something that doesn't describe the project, instead going to plugin configuration
- I don't consider this backwards compatible - we don't want to keep both as its confusing, which means deprecating the first, which means removing it before the final 2.0 release. I wouldn't be particularly happy with that.
I hope this is reasonable?
> Support <includes> and <excludes> for the source and testSource directories.
> ----------------------------------------------------------------------------
>
> Key: MNG-643
> URL: http://jira.codehaus.org/browse/MNG-643
> Project: Maven 2
> Type: Improvement
> Components: maven-plugins
> Versions: 2.0-alpha-3
> Environment: jdk 1.4.x, gentoo linux
> Reporter: Corridor Software Developer
> Fix For: 2.0-beta-2
>
> Original Estimate: 1 week
> Remaining: 1 week
>
> m2 currently supports FileSets in <resources> and <testResources> which allow for the inclusion and exclusion of files based on a pattern.
> Users may benefit from having this functionality in the source and testSource directory definitions as well. Here are some scenarios:
> 1) a volative package of java files may be excluded from a build to permit developers to continue building the other source files without having to delete or resolve issues for the problem files.
> 2) Source files and test source files may be kept in the same source tree in the same manner that resources and testResources may currently be kept in a single directory.
> 3) The change will allow for a parent pom.xml which applies a custom plugin against all source files for subprojects (modules) and subprojects which only compile subsets of these files to all point at the same directory.
> 4) Some development environments keep their source files in a single directory regardless of the deployment breakout. One reason is it isn't always obvious which artifact a particular source file is located in and consolidation eliminates the need to look around.
> 5) Elegant way of continuing to maintain Maven's one project one source set mantra in a multi-project environment without increasing the number of source directories.
> In an effort to avoid breaking the existing pom format, the following tags would be supported:
> <sourceDirectory>../../src/java</sourceDirectory>
> xor
> <source>
> <directory>../../src/java</directory>
> <includes>
> <include>**/package/*.java</include>
> </includes>
> <excludes>
> <exclude>**/*Test.java</exclude>
> </excludes>
> </source>
> and
> <testSourceDirectory>../../src/java</testSourceDirectory>
> xor
> <testSource>
> <directory>../../src/java</directory>
> <includes>
> <include>**/*Test.java</include>
> </includes>
> </testSource>
> This issue is NOT endorsing the support of multiple source directories. It would simply be possible to exclude some source files from the single directory.
> The change creates a path for deprecating the existing format later if desired.
> The change would not break existing pom.xml files.
> If a patch is not included with this issue, expect one soon. This f(x) is a blocker for our development environment because we have several critical tools which traverse all source files in a company project, not just a single artifact's files. So either support for multiple source directories by a parent project (ugh!) or filters on a single directory is a must have. I am currently working on the patch.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Updated: (MNG-643) Support and
for the source and testSource directories.
Posted by Kris Bravo <kr...@corridor-software.us>.
Assuming that filters could be set for the compile and testCompile goals,
passing them as parameters to the mojo would work just fine. I'll update
the ticket and add a patch later today.
Thanks btw. This one is very important to me, as much so as the xml beans
plugin was.
Kris
> [ http://jira.codehaus.org/browse/MNG-643?page=all ]
>
> Brett Porter updated MNG-643:
> -----------------------------
>
> Priority: Major (was: Blocker)
> Fix Version: 2.0-beta-2
> Component: (was: maven-model)
> maven-plugins
>
> I'm all for including this, but let's just expose it as parameters of the
> compiler mojo. Reasons:
>
> 1) that's fine, but it's not project metadata
> 2) that's bad, we should not support it in the metadata. For example, it
> won't map to an IDEA project
> 3) belongs in that particular plugin's configuration, its not project
> metadata
> 4, 5) I don't understand your points on these ones, sorry
>
> I'm -1 to the pom format mentioned above:
> - would rather not introduce metadata for something that doesn't describe
> the project, instead going to plugin configuration
> - I don't consider this backwards compatible - we don't want to keep both
> as its confusing, which means deprecating the first, which means removing
> it before the final 2.0 release. I wouldn't be particularly happy with
> that.
>
> I hope this is reasonable?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org