On 25 Jun 07, at 10:16 PM 25 Jun 07, Jochen Wiedmann wrote:
Hi,
from using the debugger, I now know that the Contextualizable
interface in use by the Maven core is from the maven-2.0.7 uber jar,
as suspected. From the jar files info
(META-INF/maven/.../plexus-container-default), this is versio
Hi,
from using the debugger, I now know that the Contextualizable
interface in use by the Maven core is from the maven-2.0.7 uber jar,
as suspected. From the jar files info
(META-INF/maven/.../plexus-container-default), this is version
1.0-alpha-9-stable-1, the same version I am using. Neverthele
On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote:
I like this approach, and I think it's just a slightly more
detailed version
of what some of us are already trying to do when we put together
major new
pieces for Maven. I agree with Eric that any API or behavioral
change should
probabl
On 25 Jun 07, at 6:59 PM 25 Jun 07, Eric Redmond wrote:
I kind of like the idea of this process applying to any API change
- even if
it's just a bug fix, not necessarily a feature request.
It would also be nice to either have the "Work" articles under
"Work in
Progress" themselves contain
On 25 Jun 07, at 6:55 PM 25 Jun 07, Barrie Treloar wrote:
Looks good.
Basically it revolves around making sure things are documented in the
Wiki and providing a clear record of the evolution of the project
that anyone can follow at any point in time. So far from perfect but
I think a good sta
I like this approach, and I think it's just a slightly more detailed version
of what some of us are already trying to do when we put together major new
pieces for Maven. I agree with Eric that any API or behavioral change should
probably follow this process, basically anything that could change wh
I kind of like the idea of this process applying to any API change - even if
it's just a bug fix, not necessarily a feature request.
It would also be nice to either have the "Work" articles under "Work in
Progress" themselves contain contain the related JIRA issues (since there
could be more than
Looks good.
Basically it revolves around making sure things are documented in the
Wiki and providing a clear record of the evolution of the project
that anyone can follow at any point in time. So far from perfect but
I think a good starting point and I would like to field feedback so I
can impro
On 25 Jun 07, at 4:11 PM 25 Jun 07, Jochen Wiedmann wrote:
On 6/26/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
You probably have the plexus double jar problem. We separated the API
and implementation JARs and you're pulling in an old version of
plexus which has everything and then plugin whi
On 6/26/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
You probably have the plexus double jar problem. We separated the API
and implementation JARs and you're pulling in an old version of
plexus which has everything and then plugin which must be pulling in
the API jar. Because they come from diff
Hi,
As part of trying to make the whole process of making changes and
adding new features transparent to everyone involved I've whipped up
a little sketch for perusal:
http://people.apache.org/~jvanzyl/DevProcess.png
Basically it revolves around making sure things are documented in the
W
On 25 Jun 07, at 3:01 PM 25 Jun 07, Jochen Wiedmann wrote:
Hi,
I've got a Mojo, which implements the Contextualizable interface.
However, the contextualizable(Context) method is not invoked: When
running maven-2.0.7 in the debugger, I can watch that the
ContextualizePhase is executed, but the
Hi,
I've got a Mojo, which implements the Contextualizable interface.
However, the contextualizable(Context) method is not invoked: When
running maven-2.0.7 in the debugger, I can watch that the
ContextualizePhase is executed, but the check "object instanceof
Contextualizable" fails.
Any ideas,
Mark,
Can you help me make proposals like this more visible not only to
developers who might be interested, but to folks looking in at the
project for the first time.
I am trying to collect all pertinent information to the project here:
http://docs.codehaus.org/display/MAVEN/Home
And I've
On 25 Jun 07, at 9:29 AM 25 Jun 07, Mark Hobson wrote:
On 24/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
For the branch if it was 100% non-invasive i.e did not interfere at
all with _anything_ setup currently, did not change the default
conflict resolver and was undetectable by the common
On 25/06/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Mark Hobson wrote:
> Now, there are three solutions: 1) Update all other components that
> also depend on this dependency so there are no version conflicts; 2)
> Add the bug fix version to the main project's depMan; 3) Rely on the
> conflic
On 24/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
For the branch if it was 100% non-invasive i.e did not interfere at
all with _anything_ setup currently, did not change the default
conflict resolver and was undetectable by the common user, and you
took responsibility and ownership of any pr
On 2007-06-25 17:22:36 +0200, "Eric Redmond" <[EMAIL PROTECTED]> said:
This was my first course of action - and still the preferred as it it
pre-compilation. However, there are a couple problems using QDox - which I'd
be interested to know about if you have overcome them:
1) Referring to const
On 24/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Sorry :(
At the time, the repository data (mostly converted from m1) wasn't
suited to it and you got things you didn't expect. I always expected
you'd be able to turn it on and manage the dependencies properly but
the implementation of that di
On 2007-06-25 17:07:37 +0200, Jason van Zyl <[EMAIL PROTECTED]> said:
On 25 Jun 07, at 3:41 AM 25 Jun 07, Jochen Kuhnle wrote:
Hi,
I'd like to put another patch up for discussion. I have attached [1]
and [2] to the Jira issue. These patches provide (yet another :-)
extension to use JDK 1
This was my first course of action - and still the preferred as it it
pre-compilation. However, there are a couple problems using QDox - which I'd
be interested to know about if you have overcome them:
1) Referring to constants that exist in compiled dependencies
2) Amalgamated values, such as:
On 25 Jun 07, at 3:41 AM 25 Jun 07, Jochen Kuhnle wrote:
Hi,
I'd like to put another patch up for discussion. I have attached
[1] and [2] to the Jira issue. These patches provide (yet
another :-) extension to use JDK 1.5+ annotations for Mojos. The
consist of the annotations [1] and a ne
If you want to actively start designing it then put it in here:
http://docs.codehaus.org/display/MAVEN/Home
In the "Design in Progress"
I think there are relatively few people interested (I am but too
swamped to help you ATM) and this will get lost in the shuffle and if
you put in the Wiki
Hi,
I'd like to put another patch up for discussion. I have attached [1]
and [2] to the Jira issue. These patches provide (yet another :-)
extension to use JDK 1.5+ annotations for Mojos. The consist of the
annotations [1] and a new descriptor extractor [2] that uses QDOX 1.6.3.
The main fea
Dear Community,
The Apache Maven team is pleased to announce the release of Maven 1.1!
Maven is a project management and project comprehension tool. Maven is
based on the concept of a project object model: builds, documentation
creation, site publication, and distribution publication are all
con
Hey,
I've been thinking about toolchains support lately. Here's what I came
up with, as a starter for discussion.
Goal:
Have a way for plugins to discover what JDK (or other tools) are to
be used, without configuring the plugins. The current Maven way of
achieving this is to run maven itself w
Mark Hobson wrote:
On 22/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
> As mentioned above, this requires a change in the Maven installation
> rather than the POM. Obviously far from ideal, but I'm happy to live
> with this for the hug
I actually have maven 2.1 set up in continuum. There was one minor
stability quirk that should be fixed now, so I'm going to upgrade to
the latest svn and then see how it goes.
If it works for a little while I was going to propose using it as CI,
since the ci.sh script for trunk has been tu
28 matches
Mail list logo
