You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2011/12/12 14:11:43 UTC
One other fissile idea, the maven plugins
I think that there might be an advantage in declaring the maven
plugins to be an independent top-level that we release after a release
of the core product, (and perhaps release in-between as needed).
There's a pattern to maven plugin projects at maven.apache.org or the
Mojo project at codehaus, and that pattern has some advantages, if
only comparability and familiarity. We could use the invoker for
tests, etc.
What do folks think?
Re: One other fissile idea, the maven plugins
Posted by Willem Jiang <wi...@gmail.com>.
On Tue Dec 13 00:56:21 2011, Daniel Kulp wrote:
> On Monday, December 12, 2011 11:41:34 AM Benson Margulies wrote:
>> I'll answer your question with a question.
>>
>> Could the maven plugins be in the build last, so that they could have
>> the same sort of integration tests as all the maven plugins at Maven
>> and Mojo?
>
> Well, no. We need the plugins (well, at least the wsdl2java one) fairly
> early as we use it to generate a LOT of code that the unit tests and system
> tests use all over the place. The only other option would be to use exec
> plugin or something to call off to the wsdl2java command line stuff which
> would really suck.
>
>> If so, I completely withdraw my idea. If not, I guess I
>> can't make a really good argument, and the tests could just live 'over
>> there' in systests as they do now.
>
> Well, there is another option. There is no reason why the systests for the
> plugins need to be in /systest. Feel free to create a /maven-plugins/systests
> or something and move them there. The services (like the sts) pretty much do
> that now. That way, you can just go into /maven-plugins and run mvn there
> and not run the full build and such.
>
> I guess the question really is "what artifacts do you need from CXF to write
> proper ittests for the plugin?" Is it just the same things that are needed
> to run the plugins or do you need more? I'm certainly OK with requiring a
> "mvn -Pfastinstall" prior to running the itests if that would get the
> artifacts that are needed installed.
fastinstall is a handy way. That is how I found the wsdl2java maven
plugin doesn't work by running the system test after that.
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: One other fissile idea, the maven plugins
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, December 12, 2011 11:41:34 AM Benson Margulies wrote:
> I'll answer your question with a question.
>
> Could the maven plugins be in the build last, so that they could have
> the same sort of integration tests as all the maven plugins at Maven
> and Mojo?
Well, no. We need the plugins (well, at least the wsdl2java one) fairly
early as we use it to generate a LOT of code that the unit tests and system
tests use all over the place. The only other option would be to use exec
plugin or something to call off to the wsdl2java command line stuff which
would really suck.
> If so, I completely withdraw my idea. If not, I guess I
> can't make a really good argument, and the tests could just live 'over
> there' in systests as they do now.
Well, there is another option. There is no reason why the systests for the
plugins need to be in /systest. Feel free to create a /maven-plugins/systests
or something and move them there. The services (like the sts) pretty much do
that now. That way, you can just go into /maven-plugins and run mvn there
and not run the full build and such.
I guess the question really is "what artifacts do you need from CXF to write
proper ittests for the plugin?" Is it just the same things that are needed
to run the plugins or do you need more? I'm certainly OK with requiring a
"mvn -Pfastinstall" prior to running the itests if that would get the
artifacts that are needed installed.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: One other fissile idea, the maven plugins
Posted by Benson Margulies <bi...@gmail.com>.
I'll answer your question with a question.
Could the maven plugins be in the build last, so that they could have
the same sort of integration tests as all the maven plugins at Maven
and Mojo? If so, I completely withdraw my idea. If not, I guess I
can't make a really good argument, and the tests could just live 'over
there' in systests as they do now.
Re: One other fissile idea, the maven plugins
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, December 12, 2011 8:11:43 AM Benson Margulies wrote:
> I think that there might be an advantage in declaring the maven
> plugins to be an independent top-level that we release after a release
> of the core product, (and perhaps release in-between as needed).
> There's a pattern to maven plugin projects at maven.apache.org or the
> Mojo project at codehaus, and that pattern has some advantages, if
> only comparability and familiarity. We could use the invoker for
> tests, etc.
>
> What do folks think?
Well, I guess the question is what advantage do you see in it? I'm honestly
failing to see one.
There is pretty much never a time when we would release the core and not
release the maven plugins as we'd need to the plugins updated to grab the
fixes we stuck in core. I don't think we've ever had a release that didn't
fix something in the code generation or wsdl processing or something.
What's more, because the plugins currently use the dependency artifacts of the
project to resolve various things (for example: get the exsh -true flags to
work) and setup classloaders, the plugin MUST use the same version of CXF as
the project uses or unpredictable results might occur. You'd likely end up
with various bus extensions defined and loaded twice or other weird things.
With how often we release, I'm not seeing a HUGE advantage to having extra
mid-release plugins releases. If we were like some other projects that
released once a year or so, sure. I'd definitely understand that. But then
again, IMO, that just works around the "real" problem of only releasing once a
year. :-)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com