On 08/07/2008, at 1:47 AM, John Casey wrote:
Jason's referring to a ruby script I wrote to lookup the version
string for a particular staged project, for use in the stage:copy
mojo. This allows us to setup generic promotion scripts in a CI
environment like Hudson. I've committed this scrip
On 7-Jul-08, at 10:37 PM, Brett Porter wrote:
On 08/07/2008, at 11:59 AM, Brian Fox wrote:
You mean bootstrap first, then use that build to run
release:prepare...?
I would expect release:prepare to be run normally, but the bootstrap
to be used in release:perform if this is the case.
I will setup a standard job to wipe the repo. All these tests needs to
work from scratch on any machine with a clean repo. And figure out
what are install/deploy problems and what are actual bugs.
On 7-Jul-08, at 10:14 PM, Brett Porter wrote:
On 08/07/2008, at 9:49 AM, Jason van Zyl wrote:
It would have been the last good build from the bootstrap so
effectively that, yes.
On 7-Jul-08, at 9:59 PM, Brian Fox wrote:
You mean bootstrap first, then use that build to run
release:prepare...?
--Brian
On Jul 7, 2008, at 6:13 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
I'm w
On 08/07/2008, at 11:59 AM, Brian Fox wrote:
You mean bootstrap first, then use that build to run
release:prepare...?
I would expect release:prepare to be run normally, but the bootstrap
to be used in release:perform if this is the case.
I'm working release planning, and I want to define
On Tue, Jul 8, 2008 at 1:49 AM, Oleg Gusakov
<[EMAIL PROTECTED]> wrote:
> To clarify: the new resolver only cares about metadata, not actual binary.
> Current artifact, even as late as 3.0-SN, dictates that even when you try to
> get artifact metadata, you get all the goods in the local repo, and t
On 08/07/2008, at 9:49 AM, Jason van Zyl wrote:
I have the start of all the jobs running in the Hudson Zone @ Apache
and we have the same ITs that were failing yesterday failing on
Solaris:
http://hudson.zones.apache.org/hudson/view/Maven/
Was that because the artifact snapshot had not y
You mean bootstrap first, then use that build to run release:prepare...?
--Brian
On Jul 7, 2008, at 6:13 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
I'm working release planning, and I want to define how we actually
build Maven for a release.
For me it essentially boils down to:
Us
Hi Dennis,
Do you plan to merge your change in the trunk?
Cheers,
Vincent
2008/7/7, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: dennisl
> Date: Mon Jul 7 16:40:58 2008
> New Revision: 674674
>
> URL: http://svn.apache.org/viewvc?rev=674674&view=rev
> Log:
> o Use Clirr to make sure t
I have the start of all the jobs running in the Hudson Zone @ Apache
and we have the same ITs that were failing yesterday failing on Solaris:
http://hudson.zones.apache.org/hudson/view/Maven/
I am creating a little script so that I can create the Hudson setup in
3 minutes on any node. So I'm
Hi,
I'm working release planning, and I want to define how we actually
build Maven for a release.
For me it essentially boils down to:
Use the last bootstrap version of the build to produce the version of
Maven for the given release.
I think this lets us remain internally self-consistent
you may want ping java.net ws group, they own this plugin
-D
On Mon, Jul 7, 2008 at 9:15 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> BTW, I didn't get more success with tools.jar in plugin defs :
>
> [INFO]
>
> [ERROR] BUI
Hi All,
I am just a reader, but I would like to ask everyone who is sending to
this mailing list to pay little bit of attention to what you are sending
here. For instance, email quoted below have about two pages of signatures
and other system information that adds lots of visual noise to the em
On 08/07/2008, at 3:28 AM, Igor Fedorenko wrote:
Brett,
Out of curiosity. It seems that your fix for MARTIFACT-25 only
caches missing pom.xml lookup. Where is the logic that will prevent
maven from repeatedly hitting remote repositories for actual
artifacts?
I'd looked at the linked is
Brett,
Out of curiosity. It seems that your fix for MARTIFACT-25 only caches
missing pom.xml lookup. Where is the logic that will prevent maven from
repeatedly hitting remote repositories for actual artifacts?
Brett Porter wrote:
Hi Oleg,
I think you are good to go now for the release. I've
Igor just found another problem, in the Wagon manager downloading
things repeatedly. We're going to take a look at that.
On 7-Jul-08, at 1:08 PM, Brett Porter wrote:
Hi Oleg,
I think you are good to go now for the release. I've fixed the
additional issues that I'd found.
I'm just running
Hi Oleg,
I think you are good to go now for the release. I've fixed the
additional issues that I'd found.
I'm just running the integration tests again locally to confirm, but
I'd say go for it whenever you're ready. All the instructions are on
the site for setting up settings, signatures,
On 08/07/2008, at 2:38 AM, Oleg Gusakov wrote:
Jason van Zyl wrote:
On 7-Jul-08, at 12:19 PM, Oleg Gusakov wrote:
That's exactly what the problem is.
To clarify: the new resolver only cares about metadata, not actual
binary. Current artifact, even as late as 3.0-SN, dictates that
eve
Jason van Zyl wrote:
On 7-Jul-08, at 12:19 PM, Oleg Gusakov wrote:
That's exactly what the problem is.
To clarify: the new resolver only cares about metadata, not actual
binary. Current artifact, even as late as 3.0-SN, dictates that even
when you try to get artifact metadata, you get all
On 7-Jul-08, at 12:19 PM, Oleg Gusakov wrote:
That's exactly what the problem is.
To clarify: the new resolver only cares about metadata, not actual
binary. Current artifact, even as late as 3.0-SN, dictates that even
when you try to get artifact metadata, you get all the goods in the
lo
Jason van Zyl wrote:
On 7-Jul-08, at 10:19 AM, Ralph Goers wrote:
Jason van Zyl wrote:
On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that
maven-project-2.0, maven-project
BTW, I didn't get more success with tools.jar in plugin defs :
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing: wsgen [-d,
C:\workspace\slib-er
On 7-Jul-08, at 10:42 AM, Ralph Goers wrote:
Jason van Zyl wrote:
It's all part of looking at the metadata. All the stuff gets
downloaded and then there is an artifact filter which blocks all
artifacts that are in the distribution. If the metadata was pulled
in first. Then it could be
> the dependeny must in
yes, but there is no mention about this on the plugin doc ;(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
the dependeny must in
-D
On Mon, Jul 7, 2008 at 8:57 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
> Well the pom you could see :
>
>
>
>
> default-tools.jar
>
>
> java.vendor
> Sun Microsystems Inc.
>
>
>
>
> com
Well the pom you could see :
default-tools.jar
java.vendor
Sun Microsystems Inc.
com.sun
tools
1.5.0
system
${java.home}/../lib/tools.jar
Jason van Zyl wrote:
There are groups there for Maven 2.1, Plexus, Maven IDE (really
embedder consumers), and I will also limit the plugins to the default
lifecycles of the commonly used packagings like JAR, and WAR. John has
also started creating automated ways to release to stage, and
su
Caused by: java.lang.NoClassDefFoundError: com.sun.tools.apt.Main
you forgot to include tool.jar, check the plugin doc for exampl
-D
On Mon, Jul 7, 2008 at 7:23 AM, Henri Gomez <[EMAIL PROTECTED]> wrote:
>> A possible workaround: You could try the CXF plugins. They generate
>> JAX-WS complia
Jason van Zyl wrote:
It's all part of looking at the metadata. All the stuff gets
downloaded and then there is an artifact filter which blocks all
artifacts that are in the distribution. If the metadata was pulled in
first. Then it could be compared with what is in the distribution,
along w
On 7-Jul-08, at 10:19 AM, Ralph Goers wrote:
Jason van Zyl wrote:
On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that maven-
project-2.0, maven-project-2.0.6, maven-2.0.7, a
> A possible workaround: You could try the CXF plugins. They generate
> JAX-WS compliant code.
Why not as a quick workaround but we should stick with JAXWS 2.1.4
impl for now ;(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Jason van Zyl wrote:
On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that
maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
maven-project-2.0.9 were downloaded, installed
A possible workaround: You could try the CXF plugins. They generate
JAX-WS compliant code.
Dan
On Jul 7, 2008, at 10:02 AM, Henri Gomez wrote:
Hi to all,
We still get errors with jaxws-maven-plugin when were using a non
Sun JDK.
DEBUG] jaxws:wsgen args: [-d,
C:\workspace\slib-ws-
Vincent Siveton wrote:
Hi,
2008/7/5, Benjamin Bentmann <[EMAIL PROTECTED]>:
Vincent Siveton wrote:
http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions
code.apt
* <>: Document public interfaces well, i.e. all non-trivial
public and protected functions should
Hi to all,
We still get errors with jaxws-maven-plugin when were using a non Sun JDK.
DEBUG] jaxws:wsgen args: [-d,
C:\workspace\slib-ws-core-service\target\classes, -cp,
C:\workspace\slib-ws-core-service\target\classes;c:\maven-repository\com\sun\xml\ws\jaxws-rt\2.1.4\jaxws-rt-2.1.4.jar;c:\maven
On 07/07/2008, at 11:32 PM, Jason van Zyl wrote:
But is that hiding another bug? We are wiping out the artifacts
once a day on Hudson, but everyone seems to be able to run them
locally. So now we're just nuking everything but is that just
hiding a dependency resolution bug? I hate just did
On 7-Jul-08, at 9:17 AM, Brett Porter wrote:
On 07/07/2008, at 11:00 PM, Jason van Zyl wrote:
On 7-Jul-08, at 8:42 AM, Brett Porter wrote:
What does that mean. For 13 days it bubbles and then starts
magically working? Something must have changed.
Yes, I committed a fix for your two f
On 07/07/2008, at 11:00 PM, Jason van Zyl wrote:
On 7-Jul-08, at 8:42 AM, Brett Porter wrote:
What does that mean. For 13 days it bubbles and then starts
magically working? Something must have changed.
Yes, I committed a fix for your two failures, and my two failures,
and a bit more c
On 7-Jul-08, at 8:42 AM, Brett Porter wrote:
What does that mean. For 13 days it bubbles and then starts
magically working? Something must have changed.
Yes, I committed a fix for your two failures, and my two failures,
and a bit more cleanup, which all bubbled through CI eventually and
On 07/07/2008, at 10:37 PM, Jason van Zyl wrote:
On 6-Jul-08, at 11:32 PM, Brett Porter wrote:
Yes, and I thought John had fixed the offending code in Maven
Artifact - and the ITs seem to be picking up those changes. Maybe
there's a further case that needs to be addressed?
Ok, I think
On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that maven-
project-2.0, maven-project-2.0.6, maven-2.0.7, and maven-
project-2.0.9 were downloaded, installed into the local repo
On 6-Jul-08, at 11:32 PM, Brett Porter wrote:
Yes, and I thought John had fixed the offending code in Maven
Artifact - and the ITs seem to be picking up those changes. Maybe
there's a further case that needs to be addressed?
Ok, I think this particular circumstance is fixed by the time it
Yes, looking at the log it is clear that they are ignored. Yet when I
was running under my IntelliJ debugger in one case it actually stepped
into the 2.0 version of DefaultMavenProjectBuilder. I don't really know
why. But I couldn't debug it since I had the 2.0.9 version of the source
and it wa
Jeg vil være borte fra kontoret fra og med 07.07.2008 til og med
04.08.2008.
Jeg vil svare på meldingen når jeg kommer tilbake.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Actually, after looking at the code a little bit it looks like this can
be done without needing to modify the install or deploy plugins at all.
This should just be a few lines in DefaultMavenProjectBuilder (my
favorite piece of code!).
Ralph
Ralph Goers wrote:
I've just run into the problem i
Yes.
Considering that Maven will actually only use the built-in ones at
runtime for plugins it is actually quite silly to download all the
other ones for plugins.
Though this is really indicative of a wider problem where we don't do
much in the way of intelligent resolution of versions. H
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that
maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
maven-project-2.0.9 were downloaded, installed into the local repo and
then used in the build. As you would expect t
47 matches
Mail list logo
