Hi,
These are just brief notes of what we discussed at the meetup @ ApacheCon last
night. Typed on an ipod, so perhaps kind of brief - others might want to
annotate.
Attended:
Committers: Brian, Ralph, Brett, Carlos
Others: Lennart Jörelid, Ray Whitmer
Started late due to keysigning.
* What
noone wants an enforcer release?
On Tue, Nov 2, 2010 at 5:52 PM, Brian Fox bri...@infinity.nu wrote:
Hi,
Take 2, I added MENFORCER-109.
Changelog:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=13616
Staging repo:
I didn't see the take 2... make it so
+1
--jason
On Nov 4, 2010, at 10:52 AM, Brian Fox wrote:
noone wants an enforcer release?
On Tue, Nov 2, 2010 at 5:52 PM, Brian Fox bri...@infinity.nu wrote:
Hi,
Take 2, I added MENFORCER-109.
Changelog:
I'm not sure I understand. Is the proposal here to deploy non-XML project
descriptors to the repository in addition to the standard pom? If so,
what is the point?
In the case of the Clojure dialect there will be two other implementations
using the same dialect. Lein, Cake, and Polyglot
Le Thu, 4 Nov 2010 13:52:05 -0400,
Brian Fox bri...@infinity.nu a écrit :
noone wants an enforcer release?
Arch I said +1 but not on this one, was fine for me on the take 1...
so you have at least my +1 ;)
On Tue, Nov 2, 2010 at 5:52 PM, Brian Fox bri...@infinity.nu wrote:
Hi,
Take
If I were to clean this up and construct an enforcer rule that
demanded adherence to the letter of the law of the apache version
standard, is something that would be allowed into the maven enforcer
plugin?
Given a proper rule with tests, I would unlikely reject it out of hand.
Or would the
On 4 November 2010 18:04, Brian Fox bri...@infinity.nu wrote:
I'm not sure I understand. Is the proposal here to deploy non-XML project
descriptors to the repository in addition to the standard pom? If so,
what is the point?
In the case of the Clojure dialect there will be two other
Missed the take 2
+1
-Stephen
On 4 November 2010 17:52, Brian Fox bri...@infinity.nu wrote:
noone wants an enforcer release?
On Tue, Nov 2, 2010 at 5:52 PM, Brian Fox bri...@infinity.nu wrote:
Hi,
Take 2, I added MENFORCER-109.
Changelog:
+1
-olivier
Le 2 nov. 2010 22:52, Brian Fox bri...@infinity.nu a écrit :
Hi,
Take 2, I added MENFORCER-109.
Changelog:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=13616
Staging repo:
https://repository.apache.org/content/groups/maven_promotion-013/
( i promoted it
Seems reasonable, build a helper library to run clirr and analyze it's
results, allow the clirr plugin to use it in it's existing manner, or by an
enforcer rule.
That fact that it's clirr under the hood of that enforcer rule will be
completely abstracted. This will be a rule to enforce apache
On Thu, Nov 4, 2010 at 11:28 AM, Rex Hoffman r...@e-hoffman.org wrote:
Seems reasonable, build a helper library to run clirr and analyze it's
results, allow the clirr plugin to use it in it's existing manner, or by an
enforcer rule.
That fact that it's clirr under the hood of that enforcer
On Nov 4, 2010, at 7:04 PM, Brian Fox wrote:
I'm not sure I understand. Is the proposal here to deploy non-XML project
descriptors to the repository in addition to the standard pom? If so,
what is the point?
In the case of the Clojure dialect there will be two other implementations
Nah, i'll just release it again.
On Thu, Nov 4, 2010 at 2:31 PM, Rex Hoffman r...@e-hoffman.org wrote:
On Thu, Nov 4, 2010 at 11:28 AM, Rex Hoffman r...@e-hoffman.org wrote:
Seems reasonable, build a helper library to run clirr and analyze it's
results, allow the clirr plugin to use it in
So if they wanted to we can't stop them using what's available in Aether APIs
anyway. So I suppose we could leave it up to them. I don't see the big deal
really.
Sure but lets give them a standard to follow for this and try to
prevent it from exploding randomly.
+1
Arnaud
On Nov 4, 2010, at 7:23 PM, Olivier Lamy wrote:
+1
-olivier
Le 2 nov. 2010 22:52, Brian Fox bri...@infinity.nu a écrit :
Hi,
Take 2, I added MENFORCER-109.
Changelog:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=13616
Staging repo:
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
No worries. I just thought it might garner more notice and more usage if it
went out in the 1.0. Giving the rule a more powerful sense of credibility
than it might otherwise have. Just thinking of some of the managers and
architects i've been selling maven to over the past few years.
On Nov 4,
I'm hitting this problem as well and I thought I'd have a look and I
can see nothing that generates the css in the report.
I was wondering whether this problem occurred as a side effect of
MSHARED-120, but I haven't investigated further.
Before I do, does anyone have any suggestions?
Cheers
18 matches
Mail list logo
