On Jan 8, 2008 11:02 PM, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
> Take a look at the developer cookbook (
> http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook )
> and search for "resolving transitively".
> That code works for me.
That seems to do the trick, thank you!
Jochen
+1
Go for it, I'll help you make the profile to switch between 2.0.7 and
2.1 dependencies this weekend. We'll just make the 2.0.7 set the
default and I'll flip it to 2.1 as I need it myself.
On 8-Jan-08, at 2:58 PM, Raphaël Piéroni wrote:
Hello,
I would like to prepare the alpha-1 releas
+1
2008/1/9, Milos Kleint <[EMAIL PROTECTED]>:
>
> +1
>
> Milos
>
> On Jan 9, 2008 5:11 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> > +1
> >
> >
> > -Original Message-
> > From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, January 08, 2008 5:59 PM
> > To: Maven Developers
+1
Milos
On Jan 9, 2008 5:11 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> +1
>
>
> -Original Message-
> From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 08, 2008 5:59 PM
> To: Maven Developers List
> Subject: [VOTE] preparing the release of archetypeng
>
> Hello,
+1
-Original Message-
From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 5:59 PM
To: Maven Developers List
Subject: [VOTE] preparing the release of archetypeng
Hello,
I would like to prepare the alpha-1 release of the archetypeng stuff.
Preparing that relea
On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
> > IMHO, I think our approach excels in making sure this doesn't happen.
> > First and foremost, if this version range issue can be fixed, snapshots
> > will never be considered valid unless explicitly asked for. Therefore
> > snapshot deploys
> IMHO, I think our approach excels in making sure this doesn't happen.
> First and foremost, if this version range issue can be fixed, snapshots
> will never be considered valid unless explicitly asked for. Therefore
> snapshot deploys will never be a problem for me. Currently I can't even
> r
dfabulich wrote:
>
> Vote open for 72 hours.
>
> PS Since it's so close to the Gregorian New Year, I'm probably not going
> to actually deploy the release until Jan 3 at the earliest, even if the
> vote passes. :-)
>
Where are things at with this? Looking to cut a release of OpenEJB which
+1
Thanks,
--
Olivier
2008/1/5, Brett Porter <[EMAIL PROTECTED]>:
> Anyone think a 1.0.1 release with the current fixes might be in order?
>
> - Brett
>
> On 05/01/2008, at 4:42 AM, brewk9 wrote:
>
> >
> > I see this is fixed - just wondering how/when it would be available
> > in a
> > release?
Hello,
I would like to prepare the alpha-1 release of the archetypeng stuff.
Preparing that release will need to do these things:
1. move the current archetype code
(svn.apache.org/repos/asf/maven/archetype/trunk) to a branch
(.../branches/archetype-1.0.x)
2. move the current archetypeng
(svn.apa
On Jan 8, 2008 10:56 PM, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have evaluated the bug report MCLIRR-7 and must admit that I am
> stuck. Here's what I have found:
>
> Clirr requires two classloaders, one with the previous version and one
> with the current version. In order to creat
Hi,
I have evaluated the bug report MCLIRR-7 and must admit that I am
stuck. Here's what I have found:
Clirr requires two classloaders, one with the previous version and one
with the current version. In order to create the first classloader,
the clirr-maven-plugin does the following:
- Resolves
Hmm.. I had the problem with both command line 2.1-SNAPSHOT and the
embedded one in netbeans. I can't reproduce now in either. I'll file a
bug if I find reproducible steps for the issue,
Sorry to bug you.
Milos
On Jan 7, 2008 6:37 PM, John Casey <[EMAIL PROTECTED]> wrote:
> Sorry, can you provid
This vote passed with the following votes:
+1 (binding): Dennis Lundberg, Stéphane Nicoll, Vincent Siveton, Brian
E. Fox
+1 (non-binding): Olivier Lamy
No other votes.
I will move the artifacts over to the ASF repository.
Dennis Lundberg wrote:
Hi,
I'd like to release maven-pmd-plugin 2.
Vincent Siveton wrote:
>
> Could someone with rights activate the Wiki Renderer for Jira MNG project?
Here's another voice calling for this, and if it helps: P L E A S E !
;-)
Benjamin Bentmann
--
View this message in context:
http://www.nabble.com/Wiki-Renderer-for-MNG-tp14649763s177p14694
Hervé,
Think you might take a look at that as if it has anything to do with
encoding then it was most likely a result of the changes that were
made though the system for encoding in the last release.
On 8-Jan-08, at 5:12 AM, David J. M. Karlsen wrote:
I don't know if anybody have noticed t
Well, I thought the discussion was over IRC, but searching the last
year and a half, I'm at a loss.
The original reasoning here was to clean up the usage of repositories
in 2.1, and since there is no end to problems with pluginRepositories
when people actually use them, this seemed like a g
I know this was discussed a long time ago when we discovered that plugin
repos are essentially useless. The trouble is that a plugin's
dependencies are retrieved not from the plugin repo but from the regular
repo. This effectively means you must always add a plugin repo to the
repo list also, maki
I don't know if anybody have noticed this one - but it seems like a real
ugly regression bug.
See http://jira.codehaus.org/browse/MNG-3316.
If an attribute in the configuration section of a plugin containes an
attribute with name *encoding - it will result in the folling stack trace:
[INFO]
"...But at the same time I would never want another department to break my
build
by deploying a snapshot I'm not ready for. "
IMHO, I think our approach excels in making sure this doesn't happen. First
and foremost, if this version range issue can be fixed, snapshots will never
be considered val
Hello,
I'd like to commit the first version of the XWiki Sink that I have (I
have started a XWiki parser but I'm not ready yet to commit that on -
I should have a first version in about 3-4 days though).
Is it ok for me to commit it in trunk in a doxia-module-xwiki? Since
I'm not touching
All fair comments. We don't release documentation for each release.
site-deploys are independent. And we have perhaps fewer people.
But at the same time I would never want another department to break my build
by deploying a snapshot I'm not ready for.
Quite possibly we could make more use of sn
22 matches
Mail list logo
