Thanks, I dropped that tag, the staging is not at repository.apache.org any
more. I assume you already dropped it
-D
On Wed, Jan 14, 2015 at 11:49 PM, Karl Heinz Marbaise
wrote:
> Hi Dan,
>
> On 1/15/15 8:45 AM, Dan Tran wrote:
>
>> @Karl, can I go ahead to drop the staging repo and the tag? o
Hi Dan,
On 1/15/15 8:45 AM, Dan Tran wrote:
@Karl, can I go ahead to drop the staging repo and the tag? or you must be
one to do so?
You can do as far as i know...
shouldn't be a problem...
Kind regards
Karl Heinz Marbaise
Thanks
-D
On Tue, Jan 13, 2015 at 9:37 AM, Dan Tran wrote:
@De
@Karl, can I go ahead to drop the staging repo and the tag? or you must be
one to do so?
Thanks
-D
On Tue, Jan 13, 2015 at 9:37 AM, Dan Tran wrote:
> @Dennis, I committed the fix, Please verify
>
> @maven dev, this vote is cancelled
>
> @Karl, thank you for last release work, I will go thru t
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:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11134&version=20572
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=pro
There's a lot of issues in our issue tracker, not all of them should
be solved by such an extension mechanism. So while for instance
interpolation to NULL is a commonly requested feature, it'd probably
be smarter to just "fix" the problem in interpolation than to make a
whole new feature just so so
2015-01-15 4:48 GMT+01:00 Igor Fedorenko :
> Although I generally *strongly* discourage resolution of plugins and
> plugin dependencies from the reactor
Why ?
Kristian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
F
Although I generally *strongly* discourage resolution of plugins and
plugin dependencies from the reactor, it is expected to work with maven
3.0+ for regular extensions=false plugins. If you have a testcase when
it does not work, I can have a look.
--
Regards,
Igor
On 2015-01-14 10:10, Kristian
, but DSL languages is just only a fancy feature which does not solve our
major problem.
Basically the users claim that our MOJO plugin parameters should have:
+ different system properties
+ different default values
+ different data format
+ different handling of MOJO parameters
+ system properti
Surefire is in a special case, because surefire makes its own
classloader, in fact several of them. So theoretically you could dump
a blob of smalltalk into the config section of pom.xml and fire up
embedded smalltalk inside the plugin (or maybe cobol =:-). For the
single case that is surefire, any
The 6.2 checkstyle requires java 7 and it also removes (!) at least
one of the checks (RedundantThrows) which is used in all shipped
checkstyle sets and one of the integration tests. So you can no longer
use any of the builtin styles but have to use a custom style which has
the RedundantThrows chec
On Wed, Jan 14, 2015 at 1:04 PM, Tibor Digana wrote:
> Kristian, i cannot imaging how will be customizing a dependency extension.
> For instance each module should change the runOrder differently. Should I
> then build tons of module extension for each project separately?
> The extension code shou
Kristian, i cannot imaging how will be customizing a dependency extension.
For instance each module should change the runOrder differently. Should I
then build tons of module extension for each project separately?
The extension code should be in src/test/java or another module, but both
cases shoul
Hi,
Here's the link and agenda for tomorrow's Maven Dev Hangout:
https://plus.google.com/u/0/events/ca8gpunu9kht2bf3qr038s2iot0
Agenda
Anton Tanasenko (M2Eclipse committer) will be talking about and demonstrating a
new Eclipse-based editor for Modello. Modello is used heavily in Maven to
gene
Bensons' question should not be forgotten and should be answered, but I would
like to remark on Kristian's code because I see OSGi services. I like the
osgi principle more than SPI. The SPI is calling client service impl, but
here client is calling osgi/surefire service. I know Maven is not on the
On Wed, Jan 14, 2015 at 10:10 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> It is only inconvenient because maven cannot resolve the artifact from
> the current reactor, or at least it was not able to when I made
> testcases for this for surefire-providers.
>
OK, now I'm with yo
It is only inconvenient because maven cannot resolve the artifact from
the current reactor, or at least it was not able to when I made
testcases for this for surefire-providers.
This means the extension has to be in a separate project and
built/deployed entirely separate module; this is an annoyan
So, I'm confused as to why asking people to add jars to the
of a is seen as annoying or inconvenient. Can you deconfuse me?
On Wed, Jan 14, 2015 at 8:19 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> If we additionaly look for a solution that would work straight out of
> the bo
If we additionaly look for a solution that would work straight out of
the box for maven 3.0, the plugin could actually just use some kind of
loader library that would load/detect the supplied artifact into the
plugin classloader and use lazy container lookup logic when resolving
the user-supplied s
On Wed, 14 Jan 2015 12:03:54 +0100
Tibor Digana wrote:
> Is it possible to generate CHANGES.xml for Redmine automatically?
> Similar to JIRA in reporting, all the issues downloaded from the issue
> management server for particular release version.
The jredmine plugin [1] does it for you.
cheers
Agreed Benson; I find it very interesting to reduce this problem
initially, then we can grow it afterwards once we sort of understand
what it would take.
We could very well use standard DI to "export" the service-overrides
from our custom expansions module. plexus annotations should do quite
nicel
yes, let's please decouple 'how do we get more code into the classspath'
from 'how to we tell a plugin to use the code.'
For the first, we have the plugin's dependencies.
For the second, well, don't we have plexus component injection? Obviously,
there are more modern alternatives, but shouldn't w
Anders; we are discussing how the maven owl can support /both/ shotgun
*and* BFG9000 :) I sense there's small adjustments we could make
"somewhere" that could make the plugin model less monolithic.
K
2015-01-14 13:13 GMT+01:00 Anders Hammar :
>>
>> In my f*g company we have surefire plugin and a
2015-01-14 12:48 GMT+01:00 Anders Hammar :
> Wouldn't it be better to get it from the classpath of the mojo execution?
> i.e. it should be added as a dep to the plugin declaration.
That's pretty much the way we do it today with providers in surefire.
If we exported a distinct "client-api" module
>
> In my f*g company we have surefire plugin and all plugins in top parent POM
> with configuration stuff and dependencies. This way I cannot customize my
> project because i don't have rights to change top parent POM.
> I cannot say this module has this extension, this and this another because
>
Adding dependencies to plugin in user's POM is old school for me, because
this is "static" code.
Look at Gradle they use script so it cannot be old school.
Ask the Maven Users group and give them two things to choose:
+ static plugin dependencies
+ dynamic extension via scripts
In my f*g company w
>
> I've always been thinking we'd pick such stuff up from "somewhere".
> For surefire I've always figured test scope.
Wouldn't it be better to get it from the classpath of the mojo execution?
i.e. it should be added as a dep to the plugin declaration.
/Anders
> A more general solution
> would
You mean putting script code in cdata sections in the pom ? Sounds
pretty old-school to me, don't think thats the way to go.
I've always been thinking we'd pick such stuff up from "somewhere".
For surefire I've always figured test scope. A more general solution
would perhaps be to permit an entire
Is it possible to generate CHANGES.xml for Redmine automatically?
Similar to JIRA in reporting, all the issues downloaded from the issue
management server for particular release version.
Cheers
Hi Kristian, Igor,
I think i have found the way to inject custom objects into plugin execution
without SPI.
Look at this example
http://docs.codehaus.org/display/GMAVENPLUS/Examples#Examples-ExecuteScripts
The user can write a trivial script launched like this
and write a RunOrder servis by s
29 matches
Mail list logo
