Hi, i also agree with Arnaud that this would be great but i think it is almost not do-able. I tried for example to use the plexus manifest generator (= service reuse) but failed because the dependencies are not yet resolved (or something simulator) when the eclipse plugin starts.
Now to the difficulty: the plexus manifest generator will get a LOT more difficult when it is required to function in the phase the eclipse plugin is running, is that what we want? i do not think so. the plexus manifest generator should remain as simple as it is (dependent on a specific phase, and dependencies available in a specific "packaged" format). note: the plexus manifest generator is just an example! regards, Ritchie Siarhei Dudzin wrote: > Richard, > > I've noticed the plugin does invoke > ear:generate-application-xml<http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html>goal > - may be the lifecycle isn't a problem here? > > I agree with Arnaud, that way we could keep up with plugins and be more > consistent. > > Siarhei > > On Thu, Mar 20, 2008 at 10:48 AM, Arnaud HERITIER <[EMAIL PROTECTED]> > wrote: > >> We could also think to extract some part of ear/war/... plugins to >> reuse some services throught a shared library >> >> Arnaud >> >> On Thu, Mar 20, 2008 at 9:03 AM, Richard van Nieuwenhoven >> <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> The problem here is the phase in the life cycle.. The best thing would >>> be to use the generated application.xml from the ear plugin but thats >>> generated very late in the packaging phase. The eclipse plugin runs in >> a >>> very early phase to be able to generate eclipse config files also for >>> broken projects... It is even very difficult to generate the >> application >>> .xml because any of the dependent artifacts can and will not be >>> available in a packaged version (the information source of the >>> maven-ear-plugin). This means till the time we find a solution to that >>> problem, the only chance is to simulate the ear generation as best as >>> possible, and thats not easy.... The same thing is valid also for other >>> packaging's. >>> >>> Once i stated that maybe the best solution is to split the eclipse >>> plugin to be activated in different phases, and in each phase do the >>> best thing possible to make the project visible in eclipse, getting >>> better in each phase. But that would be a lot of work..... >>> >>> Does anyone have a good idea how to do this, i would love to delete the >>> tons of plugin simulation code (that will never be complete) in the >>> maven-eclipse-plugin. >>> >>> regards, >>> Ritchie >>> >>> >>> >>> Siarhei Dudzin wrote: >>> > Hi All, >>> > >>> > When I was trying to do a workaround with >>> > http://jira.jboss.org/jira/browse/JBIDE-1862 (actually seems to be >> WTP >>> > 2.0.2bug) it appears that maven-eclipse-plugin ignores >>> > application.xml that is generated by maven ear plugin. While this >> might be >>> > ok with WTP 2.0.2 you will have a problem if you use a ejb module as >> a jar >>> > (not in a project in the workspace) it adds the module anyway and >> ignores >>> > the JEE5 spec _and_ the EAR plugin settings which allow to specify >> modules >>> > and eventually exclude them. >>> > >>> > While it is possible to specify in maven-eclipse-plugin config a >> setting to >>> > use a hardcoded application.xml there are still 2 problems: >>> > >>> > 1. maven-ear-plugin already has the same setting, isn't it better to >> read >>> > it's settings? >>> > 2. If you choose to generate application.xml the plugin will put all >> modules >>> > in the application.xml (it does not check the JEE version) thus >> ignoring the >>> > JEE5 spec _and_ ear-plugin settings anyway. >>> > >>> > As soon as more users will upgrade their eclipse version lots of >> projects >>> > wont hot-deploy via WTP anymore... >>> > >>> > Your thoughts? >>> > >>> > Regards, >>> > Siarhei >>> > >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> -- >> .......................................................... >> Arnaud HERITIER >> .......................................................... >> OCTO Technology - aheritier AT octo DOT com >> www.octo.com | blog.octo.com >> .......................................................... >> ASF - aheritier AT apache DOT org >> www.apache.org | maven.apache.org >> ........................................................... >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
