Bugzilla – Full Text Bug Listing
| Summary: | [mojo] org.apache.maven.plugins:maven-antrun-plugin:run support | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Joerg Buchberger <lists> | ||||
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse, igor, mail, mkleint | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Please describe desired behaviour. Quite frankly, I don't see how maven-antrun-plugin can be integrated in Eclipse workspace efficiently and in a generic way given that it can do pretty much anything. open question then is if we shall ignore antrun plugin by default (eg. by providing a mapping that doesn't do anything) Well, we are using antrun plugin for various reasons ... - e.g. debugging property states by using ants echo - creating directories and files e.g. as part of including Hudson build numbers (using ants mkdir and touch) - copying parts of target dir (e.g. artifact etc.) to other locations, to make them _immediadetely_ available for other machine local software development which might be based on thechnology that has no perfect integration with Maven and/or vice versa. Sometimes, parts of our development are dependent on bleeding-edge technology, that is not and likely never will be integrated directly with Maven. In this cases, ant-based respectively antrun-base workarounds are the only way we can keep a Maven-only build infrastructure. With maven-only I mean, no need to setup/install other build tools and maintaining a whole separate breed of build configurations and directories. maven-antrun-plugin was the sheet anchor protecting us from build infrastructure proliferation. What is the desired behaviour when maven-antrun-plugin is bound to build lifecycle of workspace projects? What do you expect m2e to do when such projects are imported/configured inside workspace and during incremental and full workspace build? I.e. I am specifically asking about desired behaviour inside Eclipse workspace, not general use of maven-antrun-plugin. (In reply to comment #4) > What is the desired behaviour when maven-antrun-plugin is bound to build > lifecycle of workspace projects? What do you expect m2e to do when such > projects are imported/configured inside workspace and during incremental and > full workspace build? I.e. I am specifically asking about desired behaviour > inside Eclipse workspace, not general use of maven-antrun-plugin. hmm, I'm not sure whether I understand ... let me try to answer: with helios, when I open a m2e-0.12 projects properties dialog, I can access the Maven Generic Lifecycle Mapping settings for that project - there I have some influence what goals/phase are bound to clean respectively incremental workspace build - this mapping approach is somewhat limited, both by its options and my understanding of it ;-) given that antrun possibly could pretty much do anything, it seems only feasible to run it ... if the plugins execution phase is defined and its enclosing profile is active and its phase is somehow part of lifecycle mapping to either clean or incremental build ... IOW it should not run, if it is not defined as part of an active profile - or if it has execution phase not explicitly defined - or if that phase/goal is not in line with the lifecycle mapping settings of enclosing project Does that answer some aspects of your questions? And if not, please tell me what information is lacking. no plans to provide integration with maven-antrun-plugin. |
Created attachment 198904 [details] example-project 1. unpack attached example project 2. mvn install env | import/execution ---------+------------------- mvn-2 | OK mvn-3 | OK m2e-0.12 | OK m2e-1.0 | PROBLEM: No marketplace entries found to handle