On Wed, Jun 18, 2008 at 10:01 PM, Ravinder Kankanala
<[EMAIL PROTECTED]> wrote:
> I trying to create local repository in maven and I tried some commands like
> mvn clean install for default projetc but i getting this error message :
>
> I have realy no idea what the cause could be ?
> Could you pl
On 18-Jun-08, at 8:29 PM, Dan Fabulich wrote:
Brett Porter wrote:
3.0-alpha-1: released as is, with or without those few fixes I was
looking at getting in.
3.0-alpha-X: later introduce the mercury and SAT based stuff as an
optional component
3.0: when all the above is stable and the resolu
Brett Porter wrote:
On 19/06/2008, at 11:29 AM, Dan Fabulich wrote:
Brett Porter wrote:
3.0-alpha-1: released as is, with or without those few fixes I was
looking at getting in.
3.0-alpha-X: later introduce the mercury and SAT based stuff as an
optional component
3.0: when all the above is
On 19/06/2008, at 11:29 AM, Dan Fabulich wrote:
Brett Porter wrote:
3.0-alpha-1: released as is, with or without those few fixes I was
looking at getting in.
3.0-alpha-X: later introduce the mercury and SAT based stuff as an
optional component
3.0: when all the above is stable and the resol
Brett Porter wrote:
3.0-alpha-1: released as is, with or without those few fixes I was looking at
getting in.
3.0-alpha-X: later introduce the mercury and SAT based stuff as an optional
component
3.0: when all the above is stable and the resolution method is selectable
Is that how everyone se
On 18-Jun-08, at 5:12 PM, Dan Fabulich wrote:
Oleg Gusakov wrote:
SAT based resolver in the sandbox branch works differently from the
old one, and as such - it may break a few builds that rely on bugs
in the old resolver.
I think we know it will break builds that rely on bugs in the old
On 18-Jun-08, at 5:02 PM, Oleg Gusakov wrote:
SAT based resolver in the sandbox branch works differently from the
old one, and as such - it may break a few builds that rely on bugs
in the old resolver. And we need to test is more thoroughly.
You can't use this in maven-artifact yet. SAT
On 19/06/2008, at 3:47 AM, Brian E. Fox wrote:
If we are merging in the branch jason/oleg have been working on, then
the issues I mentioned are moot as they occurred in the old code. That
said, I would expect Oleg or Jason to push the release forward given
that they know the full status.
I do
On 19/06/2008, at 8:36 AM, Oleg Gusakov wrote:
Are there additional tests we could write today?
For SAT based resolver we need to
1). proof-run it against big artifacts (like maven-core, for
instance) and make sure it resolves all the transitives correctly.
Ideally - run against a represen
Dan Fabulich wrote:
Oleg Gusakov wrote:
SAT based resolver in the sandbox branch works differently from the
old one, and as such - it may break a few builds that rely on bugs in
the old resolver.
I think we know it will break builds that rely on bugs in the old
resolver, right?
Yes.
An
Oleg Gusakov wrote:
SAT based resolver in the sandbox branch works differently from the old one,
and as such - it may break a few builds that rely on bugs in the old
resolver.
I think we know it will break builds that rely on bugs in the old
resolver, right?
And we need to test is more th
SAT based resolver in the sandbox branch works differently from the old
one, and as such - it may break a few builds that rely on bugs in the
old resolver. And we need to test is more thoroughly.
The next release will still use old resolver, but the intermediate,
pre-SAT graph-based solution w
On Wed, Jun 18, 2008 at 5:08 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> In a discussion about LICENSE/NOTICE generation from maven remote resources
> plugin the result was a blocking issue in the pom content: there is no way
> to specify the copyright owner for a given artifact, it only allow
If we are merging in the branch jason/oleg have been working on, then
the issues I mentioned are moot as they occurred in the old code. That
said, I would expect Oleg or Jason to push the release forward given
that they know the full status.
-Original Message-
From: Brett Porter [mailto:[E
On 18-Jun-08, at 10:23 AM, Brett Porter wrote:
Hi,
I've fixed the code to make double deployment fail properly. Once
that is made configurable, there are no open issues for MARTIFACT
3.0 alpha 1.
MNG-3456, 3617, 3599, 3423, 3352, are on my list to check next
as they are artifact-3
Hi,
I've fixed the code to make double deployment fail properly. Once that
is made configurable, there are no open issues for MARTIFACT 3.0 alpha
1.
MNG-3456, 3617, 3599, 3423, 3352, are on my list to check next as
they are artifact-3.0 related. I might be short on time for the next
Thanks for all the info Mark, I greatly appreciate it.
We will move onto the codehaus plugin immediately.
I'm still curious how "apt" can suddenly resolve to a new plugin without any
POM changes. It seems like we wouldn't want that to happen? Or perhaps in
Maven 2.1 a "conflict resolver" would'
In a discussion about LICENSE/NOTICE generation from maven remote
resources plugin the result was a blocking issue in the pom content:
there is no way to specify the copyright owner for a given artifact, it
only allow us to specify the licenses.
I just wanted to share with you this issue, so m
I have some ideas to make this better and reduce the hurdles of 3rd
party vendors to produce easy to use plugins...i guess I need to write
that proposal.
But yes, mojo is built in.
-Original Message-
From: Mark Hobson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 8:50 AM
To: M
2008/6/18 Brian E. Fox <[EMAIL PROTECTED]>:
> The order is first pluginGroups, then apache, then mojo.
Mojo is built-in? That seems a bit counter-intuitive.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
The order is first pluginGroups, then apache, then mojo.
-Original Message-
From: Mark Hobson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 4:23 AM
To: Maven Developers List
Subject: Re: Plugin resolution
Hi Evan,
It sounds like you've picked up the apt-maven-plugin over at C
You have to check your settings.xml file from your maven installation
directory & the one from your .m2 folder and check for all the repositories
that you have defined.
also check your repository (.m2/repository) and see if the folders and jar
files exist for your workshopmavenplugin artifact.
Have you installed the workshopmavenplugin into your local repository before
trying to generate your maven poms?
mvn install:install-file
-Dfile=WorkshopMavenPlugin-1.0.jar
-DartifactId=WorkshopMavenPlugin
-DgroupId=com.mycompany.webapp1
-Dpackaging=maven-plugin -Dversion=1.0 -Dgenerat
Hi Evan,
It sounds like you've picked up the apt-maven-plugin over at Codehaus:
http://mojo.codehaus.org/apt-maven-plugin/
This has an id of org.codehaus.mojo:apt-maven-plugin, whereas the
Tobago plugin is org.apache.myfaces.tobago:maven-apt-plugin. You
shouldn't have a problem if you've declar
24 matches
Mail list logo
