I'm a bit late to catch up with this, but had a few things to note as I read
through the thread - sorry to top-top-reply.
I agree we should definitely consider a logo competition to augment this set of
contributions.
We should be cautious about using images from Native American culture - there
No, no tricks, as far as I know Plexus (and now Sisu/Guice) only inject
fully configured components. so the behaviour you describe is rather odd.
What version of Maven do you use? Is it official distribution from
Apache or something you built locally?
Not likely related, but I haven't used
Here @ SAP, EventSpies are used as well. So they are not useless, but I would
welcome a review of the convoluted and incomplete listener interfaces .
Christophe
-Original Message-
From: Milos Kleint [mailto:mkle...@gmail.com]
Sent: Donnerstag, 23. Januar 2014 08:19
To: Maven
You either end up with a custom distribution and/or using system properties.
Aside from the eventing mechanism being too convoluted, something where an
extension can be specified in the POM and downloaded if required would be more
consistent. The custom distribution route or having to invoke
On Thu, Jan 23, 2014 at 3:27 PM, Jason van Zyl ja...@takari.io wrote:
You either end up with a custom distribution and/or using system properties.
Aside from the eventing mechanism being too convoluted, something where an
extension can be specified in the POM and downloaded if required would
I think there are two separate concerns/usecases here.
Tools like m2e, netbeans or hudson need a way to push core components
without changing maven distribution or project pom.xml files. I think
system properties is the most straightforward way to do this.
Existing event listener mechanisms are
FYI, the use-case for EventSpies @ SAP is exactly the one described by Igor :
we use an event spy to instrument our Hudson/Jenkins instance to monitor the
builds.
This instrumentation MUST NOT require any pom.xml modification,
so any maven project thrown into the Hudson/Jenkins can be
Would it not be nice to be able to configure such stuff in the settings.xml?
and other thing like this is described in this issue:
https://jira.codehaus.org/browse/MNG-5356 (plus an extension is mention in the
comments)
Configuring this in the settings.xml would allow to have a single
Not for tooling integration usecase. There is usually a tight coupling
between version of the tool, like m2e, and the version of extension
getting pushed into maven core. So it should be the tool, not user, who
decides what extensions should be pushed.
There are usecases for user-configurable
You’r probably right about the tool integration, but I don’t think that
password resolving as mention in the issue counts as a tool integration. I
strongly believe this should be configurable in the settings.xml - which does
not mean it must be the only place.
Domi
On 23.01.2014, at 20:09,
Jason,
the wiki page is a really good writeup and I like the strategy to force
reporters to create a simple project which will reproduce their issue.
Regards
Mirko
--
Sent from my mobile
On Jan 23, 2014 3:33 AM, Jason van Zyl ja...@takari.io wrote:
I changed the strategy slightly as I thought
11 matches
Mail list logo
