Not a problem. Was just worried that it slipped off the radar was all. I
understand how things get in the way. Looking forward to using it though.
On Feb 13, 2008 3:31 PM, John Casey <[EMAIL PROTECTED]> wrote:
> It's still on my radar, but I haven't had time to get into all the
> issues slated fo
On 14/02/2008, at 5:09 AM, Jason van Zyl wrote:
We should find the releases, or make them put them in the wiki
before the final version.
Yep, I agree. I've done this for the Maven ones.
They all have versions somewhere. I just did a quick slurp from
source to sink to create the internal c
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic plugin
use cases, things like aggregation and use of ${reactorProjects}, that we're
running into under the current setup. I have proposals to address most of the
issues, but I'd love to hear what you would
Hi,
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current setup. I
have proposals to address most of the issues, but I'd love to hear
what you would propose.
You can sign up for a confluence one and then edit stuff in the
maven-user space. Thanks for offering to do this; it will be a
tremendous help as the Its really don't cover as much as we need.
-Original Message-
From: Christian Edward Gruber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, Febr
I started a plexus component for doing this. it is the repository crawler
(in the common module)
but it is not yet working.
Rergards,
Raphaël
2008/2/13, Brian E. Fox <[EMAIL PROTECTED]>:
> The wiki scraping is bunk. We need some metadata in the repository to contain
> this just like we do with
Well, I can certainly nail the scm plugin one (though adding it to the
maven sources and pointing the scm tag at the right location would
also do that).
My own plugin uses the invoker, but not the embedder. The exec plugin
wouldn't be too hard.
Actually, I take back my previous comment a
a project that used the maven-scm plugin and then the embedder (or exec
plugin) could snag any number of gruesome open source projects based on tags
and make sure they built
On Feb 13, 2008 2:37 PM, Christian Edward Gruber <
[EMAIL PROTECTED]> wrote:
> I have two or three I could abstract down, p
I have two or three I could abstract down, plus some teeny (project A,
Project B) samples I generated to teach people Maven.
I would actually suggest not one, but three or four, including at
least one that pulls in some common external plugins to see if
interaction breaks (says a plugin cre
It's still on my radar, but I haven't had time to get into all the
issues slated for that release yet. I think they're mostly patches,
but I'll need to set aside some time to apply them and call for the
release.
Sorry for the delay.
-john
On Feb 13, 2008, at 11:42 AM, Sejal Patel wrote:
Absolutely. We simply need a good example of a project that uses various
common tools: jars, wars, ears, assemblies, moving resources with
dependency, scanning with checkstyle/pmd/cobertura. It should have a
simulated corp pom etc. The trouble with most touchstone builds are they
are enterprise exa
How can I help? Seriously. I'd be willing to put some time into it.
Christian.
On 13-Feb-08, at 13:47 , Brian E. Fox wrote:
Yes we do have plans for a touchstone build to test against. Getting
one
made is actually the problem ;-)
-Original Message-
From: Christian Edward Gruber [m
Yes we do have plans for a touchstone build to test against. Getting one
made is actually the problem ;-)
-Original Message-
From: Christian Edward Gruber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 13, 2008 10:26 AM
To: Maven Developers List
Subject: Re: Maven and preset plugin v
The wiki scraping is bunk. We need some metadata in the repository to contain
this just like we do with the name mappings for plugins. Lets make a
metadata.xml somewhere and start recording them (first by hand, later with
tools).
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PRO
This is true, but it might be appropriate for the maven core group to
provide a criterion (or criteria) for inclusion of the new version.
Some sort of sufficiency of testing, full regression in an isolated
integration environment, etc. If the core group can set a baseline of
quality that
We should find the releases, or make them put them in the wiki before
the final version. They all have versions somewhere. I just did a
quick slurp from source to sink to create the internal catalog because
Confluence flakes out on Codehaus so it was grinding away and dying in
the eclipse i
I don't buy into the objection that simplifying the POM is "too late". If
there is not a 4.1, there will be a 5.0. Eventually the POM will change --
if it doesn't happen with attributes, it will be for another reason. The
schema dictates what is valid/invalid. If people want verbosity, let them
con
Hey guys I'm curious, what is the states of the new beta2 release? I'd like
to be able to get started on using it from an official release.
On Jan 31, 2008 6:32 PM, Paul Gier <[EMAIL PROTECTED]> wrote:
> Ok, no problem. Here are a few other issues that should be quick to fix
> when
> you have a
Thanks, I'll review the reason for that change, and see whether I can
put it back down.
-john
On Feb 12, 2008, at 4:41 PM, Dennis Lundberg wrote:
The plexus-utils upgrade will not happen unless you also changes
the prerequisites to Maven 2.0.6.
[EMAIL PROTECTED] wrote:
Author: jdcasey
Da
Hi there,
I've been chatting to Jason about making some headway with the maven
artifact improvements that have been on the cards for sometime now.
I've dug through much of the code on my travels implementing
dependency:tree, conflict resolution and integrating maven-artifact
3.x into maven 2.0.x.
Fixed in the latest snapshot (now deployed). Note that you'll now get
prompted for the "version" and "package" values, though they have the
same defaults as before so you can just enter past them.
Cheers,
Brett
On 13/02/2008, at 2:02 AM, Daniel Kulp wrote:
The new archetype plugin seems t
The Maven archetypes on that page have no versions - which I presume
is why they are RELEASE in the internal catalog. So I'm asking if we
should hard code them instead?
- Brett
On 13/02/2008, at 10:21 PM, Raphaël Piéroni wrote:
The catalog file was created from the WIki page which has vers
The catalog file was created from the WIki page which has versions.
Regards,
Raphaël
2008/2/13, Brett Porter <[EMAIL PROTECTED]>:
> I've currently set the default to match the internal catalog, which is
> the same as before: RELEASE (ie, the latest release).
>
> But all the other archetypes (non
I've currently set the default to match the internal catalog, which is
the same as before: RELEASE (ie, the latest release).
But all the other archetypes (non-maven) list versions. Should the
internal catalog list versions?
(Seems much like another discussion on super POMs, I know :D)
- Br
On 13/02/2008, at 7:15 PM, Mark Struberg wrote:
Does the refactoring of the XML give us any new functionality
besides only 'looking better'?
No, but it seems that's reason enough :) The technical underpinnings
do give the value of being able to add things to the model now,
however, and s
Does the refactoring of the XML give us any new functionality besides only
'looking better'?
And what is the price we pay? Getting non-compatible with existing poms?
Someone already mentioned
the forward compatibility once 'new' poms get their way into the repos. There
are still many
companies w
I was told today that profiles defined in the profiles.xml are inherited
and can be activated selectively in the child modules. I am skeptical,
but it's work a look.
-Original Message-
From: Wouter Hermeling [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 12, 2008 11:39 PM
To: dev@maven
27 matches
Mail list logo
