Definitely +1 !
:-)
Fabrice.
On 6/24/07, Wendy Smoak [EMAIL PROTECTED] wrote:
Archiva 1.0-alpha-2 was tagged and built on Saturday. The proposed
files, including source and binary distributions, checksums, and
signatures, can be found here:
Wendy,
even without a whitelist entry of *, this proxy connector is working for
me...
Fabrice.
On 6/23/07, Wendy Smoak [EMAIL PROTECTED] wrote:
The proxy connector in the default configuration was apparently
intended to proxy requests from internal to central, but it wasn't
proxying
+1
Emmanuel
Wendy Smoak a écrit :
Archiva 1.0-alpha-2 was tagged and built on Saturday. The proposed
files, including source and binary distributions, checksums, and
signatures, can be found here:
http://people.apache.org/builds/maven/archiva/1.0-alpha-2/
This release resolves several
+1 (from San Jose, CA)
- Joakim
Wendy Smoak wrote:
Archiva 1.0-alpha-2 was tagged and built on Saturday. The proposed
files, including source and binary distributions, checksums, and
signatures, can be found here:
http://people.apache.org/builds/maven/archiva/1.0-alpha-2/
This release
Hey Everyone! Our development team has been having some issues with
certain SNAPSHOTs deployed to Archiva being invalid. Meaning, the
artifact page doesn't display or the *.jar is not available for download
(if using Archiva version previous to 1.0-alpha-2). I haven't been able
to figure what
+1
On 6/25/07, Joakim Erdfelt [EMAIL PROTECTED] wrote:
+1 (from San Jose, CA)
- Joakim
Wendy Smoak wrote:
Archiva 1.0-alpha-2 was tagged and built on Saturday. The proposed
files, including source and binary distributions, checksums, and
signatures, can be found here:
Apropos to this and to the IT/development expectations, is the Maven
2.1.x process going to have strong infrastructure around build
automation? At this point, I think Continuum 1.1-alpha-* builds are
probably stable enough to be used for CI, and a secondary build
fresh nightly build and
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
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 huge
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
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
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
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
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
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 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
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
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
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
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
conflict
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
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
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,
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,
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
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
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
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
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
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
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
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 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
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.
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
35 matches
Mail list logo
