[
http://jira.codehaus.org/browse/MCOMPILER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222455#action_222455
]
Steve Ebersole commented on MCOMPILER-128:
------------------------------------------
Brett, when I spoke to him John said he had already been contemplating this
enhancement so I cannot speak to his previous thoughts. But specifically what
I spoke to him about was a specific use case that we have in Hibernate.
Currently Maven forced us to utilize 3 different modules, for what IMO should
easily be allowed in one; one project -> one artifact being the biggest
obstacle.
The module splits break down as:
* hibernate-core - The main Hibernate module
* hibernate-testing (depends on hibernate-core) - Contains test
"infrastructure" code that gets used by other modules and that we package up
separately for users to make it easy for them to write Hibernate-based test
cases
* hibernate-testsuite (depends on both hibernate-core and hibernate-testing) -
Obviously because we had to split hibernate-testing out, we had to split out
the testsuite as well to avoid circularity.
The concern is that hibernatee-testsuite really is the testsuite for
hibernate-core. However, it often gets overlooked and not run when developers
make changes prior to commit. So I'd like to put all these back in their
natural places. Yes just splitting the hibernate-testing into a separate
source directory and applying compilation will "work" in that it will get stuff
into the needed classpath. The issue is that the artifacts get screwed up
(hibernate-testing classes will end up in hibernate-core, and there is
additionally no easy way to build the hibernate-testing artifact for attachment
since the classes are all in one big hodge-podge).
> "Extra" Compiler mojo for non-test, non-main code
> -------------------------------------------------
>
> Key: MCOMPILER-128
> URL: http://jira.codehaus.org/browse/MCOMPILER-128
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
> Affects Versions: 2.3.1
> Reporter: John Casey
> Assignee: John Casey
> Fix For: 2.4
>
>
> It'd be nice to be able to specify another compile step in the build process,
> pointed at different source code and compiling to some alternative location.
> Using this approach, one could easily segregate test-fixture code that
> depends on the current module from the unit tests for that module, then use
> something like the assembly plugin to jar up the compiled test fixtures for
> distribution.
> Obviously, once this "extra" compile step was completed, the resulting
> location would have to be added to the appropriate classpath for test
> compilation, etc. This could be handled using a system dependency (ick) or
> something like a test-resource with filtering turned off (much the way image
> resources are handled), which would make it available on the classpath.
--
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
