Ok, stay within what's here.
I posit that the default lifecycle and binding to it with mojos provides
sufficient means of extension. So we have a lifecycle and at the other extreme
in Ant and Gradle we have an arbitrary DAG. Along that spectrum I'm not sure I
understand what you think the
Hi,
I've looked at your modifications and they look good.
I found a few more typos in the documentation that I have fixed and checked in.
On Tue, Jan 13, 2015 at 6:37 PM, Dan Tran dant...@gmail.com wrote:
@Dennis, I committed the fix, Please verify
@maven dev, this vote is cancelled
@Karl,
Thanks Dennis
-D
On Thu, Jan 15, 2015 at 12:09 PM, Dennis Lundberg denn...@apache.org
wrote:
Hi,
I've looked at your modifications and they look good.
I found a few more typos in the documentation that I have fixed and
checked in.
On Tue, Jan 13, 2015 at 6:37 PM, Dan Tran
I think that we don't need to fully open up our plugins so that anyone can
customize each aspect on the fly. We would too much hide the fact that
the execution is highly customized because some special stuff is hidden on
the classpath somewhere.
Likewise, if we allowed that sort of customization
Jason;
We have been talking at length about what we think is wrong with the
plugin model in this thread. I'm happy to hear that you have solved
things within the existing model in Takari. From what I've picked up
It sounds like you have made an even greater monotlith than what we
already have,
On Jan 15, 2015, at 2:29 PM, Andreas Gudian andreas.gud...@gmail.com wrote:
I think that we don't need to fully open up our plugins so that anyone can
customize each aspect on the fly. We would too much hide the fact that
the execution is highly customized because some special stuff is hidden
Conceptually, I believe this is a case bad separation of concerns. Build
tools and production code often require different development skills and
techniques, have different dependencies. You really need to wear two
different hats to work on the tools and production code, and I think
many devs
I believe that it is important to let the POM serve as a configuration (for
a set of Plugin-clad operations).
If we permit the POM to be the host of scripts, I suggest that overall
build stability would be compromised.
If one wants to implement a chain-of-command or extension pattern within a
True, Kristian.
But the pains of creating a Maven project A to host dependencies for
plugins in project B seem ... small in comparison to injecting dynamic
elements into the POM. Provided, of course, that one intends to re-use and
unit test the plugin extension.
2015-01-14 16:10 GMT+01:00
Hi,
The vote has passed with the following result:
+1 (binding): Jason van Zyl, Oliver Lamy, Karl Heinz Marbaise
+1 (non binding): none
I will promote the artifacts to the central repo.
Kind regards
Karl Heinz Marbaise
-
To
GitHub user hgschmie opened a pull request:
https://github.com/apache/maven-plugins/pull/42
[MCHECKSTYLE-272] Update checkstyle plugin for checkstyle-6.2
After applying the change to trunk, the changes to the integration test
poms (which load resources from the MCHECKSTYLE-272
I made all the necessary changes to run out-of-the-box with 6.2 (and
have all the integration tests etc. pass) at
https://github.com/apache/maven-plugins/pull/42
Getting this out quickly would IMHO be a benefit to the whole apache
community (compared to, say lovingly maintain backwards compat to
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?
projectId=11431version=20125
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%
20MGPG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
20DESC%2C%20priority%20DESC
Staging
We have been discussing this in the context of surefire, which uses
these extension mechanisms, so both Tibor, Andreas and I are fully
aware of what is possible. And as Jason says, there is a spectrum. I'm
not sure how the line would be drawn, since ant is very free-form
while gradle is
Hi Dan,
On 1/15/15 8:58 AM, Dan Tran wrote:
Thanks, I dropped that tag, the staging is not at repository.apache.org
http://repository.apache.org any more. I assume you already dropped it
Yeah...forgot to mention
Regards
Karl Heinz
-D
On Wed, Jan 14, 2015 at 11:49 PM, Karl Heinz
+1
On 13 January 2015 at 07:45, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi,
We solved 11 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?
projectId=11134version=20572
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%
Maybe Jason can bring some light into this discussion.
Jason?
--
View this message in context:
http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.html
Sent from the Maven Developers mailing list archive at Nabble.com.
Hi,
I need at least two binding votes...
Thanks.
Kind regards
Karl Heinz Marbaise
On 1/15/15 7:45 AM, Karl Heinz Marbaise wrote:
Hi,
here is my +1
Kind regards
Karl Heinz Marbaise
On 1/12/15 9:45 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 11 issues:
+1
On Jan 15, 2015, at 4:48 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi,
I need at least two binding votes...
Thanks.
Kind regards
Karl Heinz Marbaise
On 1/15/15 7:45 AM, Karl Heinz Marbaise wrote:
Hi,
here is my +1
Kind regards
Karl Heinz Marbaise
On 1/12/15 9:45
19 matches
Mail list logo
