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
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.
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
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]
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
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
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 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 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
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
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
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,
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
* Documentation: Document public interfaces well, i.e. all non-trivial
public and protected
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,
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,
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:
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
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 compliant
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
Well the pom you could see :
profiles
profile
!-- This is only for non MAC OS X builds, hence the property below --
iddefault-tools.jar/id
activation
property
namejava.vendor/name
valueSun Microsystems Inc./value
/property
the dependeny must in buildpluginsplugin
-D
On Mon, Jul 7, 2008 at 8:57 AM, Henri Gomez [EMAIL PROTECTED] wrote:
Well the pom you could see :
profiles
profile
!-- This is only for non MAC OS X builds, hence the property below --
iddefault-tools.jar/id
activation
the dependeny must in buildpluginsplugin
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]
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
BTW, I didn't get more success with tools.jar in plugin defs :
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing: wsgen [-d,
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,
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
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,
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
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.
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
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
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] BUILD
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
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
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=674674view=rev
Log:
o Use Clirr to make sure that we
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:
Use
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
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 then
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
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
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
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.
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
43 matches
Mail list logo
