Cool, I'll sync up with Hervé and one of us will release it.
On Nov 13, 2012, at 3:14 PM, Dennis Lundberg wrote:
> I've assigned the issue to me.
> The fix on the Maven side is to use a newer Modello Plugin version.
>
> On 2012-11-13 21:04, Jason van Zyl wrote:
>> Currently that is unassigned w
I've assigned the issue to me.
The fix on the Maven side is to use a newer Modello Plugin version.
On 2012-11-13 21:04, Jason van Zyl wrote:
> Currently that is unassigned which brings up the issue as to whether that
> issue should be there.
>
> Anything that is not assigned means no one plans t
Currently that is unassigned which brings up the issue as to whether that issue
should be there.
Anything that is not assigned means no one plans to work on them and we should
push them back in the pool.
If you want to fix that I can work with Hervé to see who wants to push out a
Modello relea
On 2012-11-13 19:45, Jason van Zyl wrote:
> There, I just added a couple macros and lined out the proposed roadmap given
> the feedback.
>
> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap
Jason,
If you have a few cycles, could you have a look at releasing Modello? We
need a new Model
There, I just added a couple macros and lined out the proposed roadmap given
the feedback.
https://cwiki.apache.org/confluence/display/MAVEN/Roadmap
On Nov 13, 2012, at 12:02 PM, Jason van Zyl wrote:
> Dan helped me reset my password so I'm good. I'll work on the roadmap now.
>
> On Nov 13, 2
Dan helped me reset my password so I'm good. I'll work on the roadmap now.
On Nov 13, 2012, at 10:44 AM, Benson Margulies wrote:
> On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl wrote:
>
>> Does this instance use for authentication? I tried my LDAP password and
>> that doesn't seem to work.
>
On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl wrote:
> Does this instance use for authentication? I tried my LDAP password and
> that doesn't seem to work.
>
I don't think it uses ldap. Have you tried password recovery?
>
> I'm trying to make a roadmap page for the proposed schedule for the
Does this instance use for authentication? I tried my LDAP password and that
doesn't seem to work.
I'm trying to make a roadmap page for the proposed schedule for the next three
releases so people can see it easier than trying to surf JIRA.
Thanks,
Jason
-
That's the existing process, where the next mojo to be executed is
discovered based on the metadata of the current one...if the current
mojo requires a fork, the mojos to be included in that fork are
calculated just before the forking mojo is executed. As you go
through the build, executing
MAIL PROTECTED]>
wrote:
Reading through the Deterministic Lifecycle Planning page...
Do these changes make it possible to create new lifecycle phases???
Imho this would really help maven to become an extendable build/
project
management tool for multiple platforms and purposes.
--
View th
/Please-comment%
3A-2.1-Lifecycle-Features-on-MAVEN-Confluence-space-
tp15170452s177p15407416.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
t: Monday, 11 February 2008 7:34 PM
> To: Maven Developers List
> Subject: [***POSSIBLE SPAM***] - Re: Please comment: 2.1
> Lifecycle Features on MAVEN Confluence space - Bayesian
> Filter detected spam
>
> From
> http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ord
Hi John,
That looks very interesting!
BTW, what is 'Just-in-time lifecycle discovery and configuration'?
Rahul
John Casey wrote:
Hi all,
I've written up the new features present in the refactored lifecycle
support for 2.1, if anyone is interested in reading it. I'd like to
hear what you
ent!)
>
>
> On Feb 11, 2008 8:44 AM, Wouter Hermeling <[EMAIL PROTECTED]> wrote:
>
> >
> > Reading through the Deterministic Lifecycle Planning page...
> >
> > Do these changes make it possible to create new lifecyc
ly help maven to become an extendable build/project
> management tool for multiple platforms and purposes.
> --
> View this message in context:
> http://www.nabble.com/Please-comment%3A-2.1-Lifecycle-Features-on-MAVEN-Confluence-space-tp15170452s177p15407
://www.nabble.com/Please-comment%3A-2.1-Lifecycle-Features-on-MAVEN-Confluence-space-tp15170452s177p15407416.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Yeah, upon thinking about this a little more, I think it could be a really
bad idea to expose the "live" BuildPlan to plugins, at least without making
it a read-only view. Instead, I'd much rather provide a second extension
point for Maven that's well-defined and well-documented like the basic Mojo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
| Right...I guess it'd help to include the URL:
|
| http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
|
| Thanks!
I generally agree with what you are saying.
You are pointing out common problems very well.
The solution
ifecycle Features on MAVEN Confluence space
yes, I see what your talking about..
And I think your might be onto something with your BuildPlanModifier
bit...It seems to me that plugins have perhaps grown a bit too...powerful in
terms of how they can effect the build.
I wonder if it might be a
yes, I see what your talking about..
And I think your might be onto something with your BuildPlanModifier
bit...It seems to me that plugins have perhaps grown a bit too...powerful in
terms of how they can effect the build.
I wonder if it might be a good time while your looking into all of this to
You know, I've been thinking about that bit, too...turning mojos off,
replacing them, etc, I mean. What I'm currently thinking is that a
build extension that carried its own configuration might be a good
alternative, though I'm not sure how well that would scale. The idea
is to introduce a
well, when your working with something that will try and predetermine how
and when plugins will run and you have something like build context/state in
play then plugins will be able to turn themselves off depending on build
state based on the context of the build up to that point...which kinda
inte
How do you see that impacting the lifecycle stuff, out of curiosity?
I did put the build context into trunk, but wound up taking it back
out because it wasn't implemented very well, and was leading to a
proliferation of separate, threadlocal-driven storage classes. I've
been thinking for aw
Do you think this will also include the build context mechanics we talked
about a long time ago? Where mojo's can communicate to each other a map of
either status or configuration settings through some third party mechanism,
perhaps the build plan this talks about. I seem to remember you putting
s
Right...I guess it'd help to include the URL:
http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
Thanks!
-john
On Jan 29, 2008, at 4:58 PM, John Casey wrote:
Hi all,
I've written up the new features present in the refactored
lifecycle support for 2.1, if anyone is int
Hi all,
I've written up the new features present in the refactored lifecycle
support for 2.1, if anyone is interested in reading it. I'd like to
hear what you all think, particularly about the emerging discussion
of aggregator plugins, pre-exec "plugins", and such taking place on
the page
26 matches
Mail list logo
