[
http://issues.ops4j.org/browse/PAXEXAM-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893#action_12893
]
Alin Dreghiciu commented on PAXEXAM-124:
----------------------------------------
I would say that maven 3 embedder should be used in mvnlive handler. I still
want to have that one in place, but not with a process call like now. This
would be an eventual option when maven 3 knows incremental build.
I do not really want to rebuild on the fly. I want, for now at least, just to
build a jar from build output directory (target/classes). Indeed not all teh
time what is there is valid but is developer choice that it uses this option.
> Better support for provisioning modules from the same project
> -------------------------------------------------------------
>
> Key: PAXEXAM-124
> URL: http://issues.ops4j.org/browse/PAXEXAM-124
> Project: Pax Exam
> Issue Type: New Feature
> Components: Core
> Reporter: Alin Dreghiciu
> Assignee: Toni Menzel
> Fix For: 1.2.0
>
>
> Most of the time one will use Pax Exam for integration tests by provisioning
> and testing modules from the same project as where the integration project
> resides. This works fine while in a maven build for example because usually
> the provisioned bundles from integration test is already build. But when
> using an IDE the most common pattern is that one will test some parts of the
> project and want to run the ITs again. This does not work as they will have
> to rebuild the changed modules first so the correct bundle content is
> provisioned, task which is error prone (you forgot and wonder why the changes
> are not in place), is time consuming and annoying.
> Will be great that there will be support in PAx Exam to avoid as much as
> possible this repetitive task. Some ideas:
> * Maven specific provisioning api based on assembly url handler (generates
> descriptor), or based on TinyBundles.
> * Best will be to just specify module name, relative to root.
> * This support will be able to find the classes to be included
> (target/classes) and generate the jar. Excellent (performance reason) will be
> to only add/remove the dif on a previous bundle.
> * This will not be quite workable for the kind of bundles where you pull in
> to the bundle external content form dependencies.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
