[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_50493 ]
John Casey commented on MNG-699:
I've applied the new lifecycles and artifact handlers here, so whatever
ejb3/par plugin implementations you want to use will have plumbing. ;)
> Add EJB3
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_50491 ]
Stephane Nicoll commented on MNG-699:
-
See MOJO-98 and MOJO-99
> Add EJB3 support in a plugin
>
>
> Key: MNG-699
> URL: http://jira.code
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_50245 ]
Brett Porter commented on MNG-699:
--
it's up to you. If you think the mojo versions are better, take those - or
combine the two.
I just think the final destination should be the Apache M
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_50196 ]
Stephane Nicoll commented on MNG-699:
-
What do we do? Do we take MOJO-98 / MOJO-99 or the plugins I have added in the
sandbox?
We also need to add the ejb3 and par lifecycles to arti
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_49734 ]
Brett Porter commented on MNG-699:
--
I agree that they should be in one spot. As long as the plugins are all
suitably licensed (ASL) including their dependencies, then I'd prefer to put
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_49729 ]
Stephane Nicoll commented on MNG-699:
-
Nothing, I just need to make sure that trygvis has committed the new lifecycle
in maven-core for par and ejb3. The plugins are in the sandbox, r
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_49720 ]
Brett Porter commented on MNG-699:
--
what is required to finish this? how do they compare/relate to MOJO-98/MOJO-99?
> Add EJB3 support in a plugin
>
>
>
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_49507 ]
Stephane Nicoll commented on MNG-699:
-
Added maven-ejb3-plugin and maven-par-plugin in the sandbox, thanks.
> Add EJB3 support in a plugin
>
>
>
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_47130 ]
Brett Porter commented on MNG-699:
--
I trust your ability to review the patch, I'll just complain later if I see
anything I don't like ;)
Why would you want to delegate application.xml g
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_47129 ]
Stephane Nicoll commented on MNG-699:
-
Yup indeed. I woud prefer delegation as well (didn't though about it). Well,
MavenArchiver could be enhanced, it does not include archiver for E
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_47112 ]
Brett Porter commented on MNG-699:
--
I'd prefer delegation over inheritence, and thought that most of the shared
code was already in MavenArchiver. If you think this can be enhanced, that
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_47105 ]
Stephane Nicoll commented on MNG-699:
-
This code redundacy annoys me.
I think we need something below AbstractMojo for that kind of things. Because,
all thoses plugins generates qui
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_46474 ]
Brett Porter commented on MNG-699:
--
unfortunately, this will mean that under the current architecture, the artifact
will not be correctly installed/deployed. I will track down the depend
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_45803 ]
David Jencks commented on MNG-699:
--
I have no particular opinion on the idea of allowing you to change the
extension of the artifact generated by the jar plugin, but would like to point
[ http://jira.codehaus.org/browse/MNG-699?page=comments#action_45801 ]
Piotr Bzdyl commented on MNG-699:
-
I still think that there should be possibility to create jar files with
extension different than just *.jar. Look at the JBoss different artifact (sar
15 matches
Mail list logo
