I think we shouldn't worry about making these actually releases cut
with the maven-release-plugin. I say we just make a build and get it
available for download. Also tag the continuum trunk accordingly.
Then we ought to try to release a new alpha every few weeks until we
have the alpha-#
CLOB is supported by most of the databases, and Oracle is the only one with
a particular API rather than plain JDBC
Quoting Brett Porter [EMAIL PROTECTED]:
Isn't Oracle the only database to offer a CLOB?
I think writing it to a file in the build results directory like the
other output makes
ok, I'll plow through the rest of the uncategorized issues now :)
jesse
On 3/12/07, Thierry Lach [EMAIL PROTECTED] wrote:
I'd like to see the JBoss integration
http://jira.codehaus.org/browse/CONTINUUM-1167 added somewhere in the alpha
process.
On 3/12/07, Erik Bengtson [EMAIL PROTECTED]
On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 11 Mar 07, at 9:48 PM 11 Mar 07, Jerome Lacoste wrote:
[...]
Some days ago we talked about trying to not expose the internal maven
plexus-utils to the projects it builds.
I have done work on trunk and am working with Torsten to
On 12 Mar 07, at 12:22 AM 12 Mar 07, Jerome Lacoste wrote:
On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 11 Mar 07, at 9:48 PM 11 Mar 07, Jerome Lacoste wrote:
[...]
Some days ago we talked about trying to not expose the internal maven
plexus-utils to the projects it builds.
Joakim Erdfelt wrote:
Databases in Archiva.
I need *desperately* to create a proper database for Archiva. Relying on
the Lucene database for all things in Archiva is not cutting it.
But I'm waffling on the database O/RM technology to use.
Here some Archiva requirements for the O/RM db
Jesse McConnell wrote:
I have gone through jira issues there were assigned to 1.1 and spread
things out a bit.
here is my criteria I used in separating out the issues:
1.1-alpha-1 - issues that need to be addressed asap before we pull
any kinda alpha
1.1-alpha-2 - higher importance issues and
Jesse McConnell wrote:
sounds good to me, imo either trunc it or maybe switch the model over
to a clob for that in the db...
I tried to make it a CLOB once but couldn't get it to work because of
some JPOX issues IIRC so for alpha-1 just chop the exception and/or
write it to a separate file
It is indeed similar but Erik's thing will build it against *all*
compatible versions, where compatible means within major upgrades (a
x.y.z pattern is assumed).
--
Trygve
Jesse McConnell wrote:
erik
I saw this issue and thought of you :)
http://jira.codehaus.org/browse/CONTINUUM-45
jesse
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more
than just surefire.
Jason van Zyl wrote:
On 12 Mar 07, at 12:22 AM 12 Mar 07, Jerome Lacoste wrote:
My current task is now to document what i have done so far.
Answers and questions inlined.
Raphaël
2007/3/12, Brett Porter [EMAIL PROTECTED]:
My basic feedback would be similar to Jason's.
Key requirements:
- backwards compatibility with existing archetypes is a definite
requirement
Is
Oups,
I forgotten to say that archetypes is the first foot a developper starts for
using maven.
This is why i'm concerned about archetypes.
I also see archetypes a examples of using maven (for example the axistools)
Raphaël
2007/3/12, Raphaël Piéroni [EMAIL PROTECTED]:
My current task is now
There is a mismatch of plexus component api and container-default by
the looks of things, unless there is some code in archiva that uses
the removed getComponentKey() method.
Andy
On 11 Mar 2007, at 20:04, Wendy Smoak wrote:
On 3/11/07, Brett Porter [EMAIL PROTECTED] wrote:
This occurs
The runtime works fine there. Check your core directory. Do you have
plexus-component-api-1.0-alpha-18.jar,
plexus-container-default-1.0-alpha-18.jar and
plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ?
Emmanuel
Brett Porter a écrit :
Emmanuel last changed the container - anything to do
On 3/12/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more
than just surefire.
I agree.
But even hiding
Hi all,
I am trying to do a release:perform on a project that creates a jar with a
classifier.
For some reason, as part of release:perform, install:install is called,
and when install:install is called _without_ being part of the build
lifecycle, it fails with the error below.
I tried
Quick updates:
1) It's definitely the classloader. If a set the contextClassLoader to
the classloader of the plugin, the RM works fine. That seems like less of
a hack so I'll go with that.
2) I THINK this is the cause of MCHECKSTYLE-65. I'll try the classloader
thing there too.
Dan
I don't know how you can get alpha-19-SNAPSHOT, but I added
plexus-component-api in archiva-plexus-runtime so it should be ok now.
Emmanuel
Wendy Smoak a écrit :
On 3/12/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
The runtime works fine there. Check your core directory. Do you have
Jason,
Back in December, you changed a bunch of plugins (PMD and Checkstyle are
definitely two of them) to use the ResourceManager instead of the custom
Locator code they had.
That seems to work fine when the plugins are part of the actual build
build, but not during a reporting run.If
On Mon, March 12, 2007 4:34 pm, Graham Leggett wrote:
Has anyone seen release:perform work with a classifier present?
I have managed to narrow this down to the deploy plugin. It seems the
deploy plugin cannot deploy a jar with a classifier. The stacktrace is
below.
[INFO] [jar:jar]
[INFO]
On 3/12/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
The runtime works fine there. Check your core directory. Do you have
plexus-component-api-1.0-alpha-18.jar,
plexus-container-default-1.0-alpha-18.jar and
plexus-appserver-host-2.0-alpha-8-SNAPSHOT.jar ?
I have:
[EMAIL PROTECTED]
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sun Mar 11 09:27:08 2007
New Revision: 516945
URL: http://svn.apache.org/viewvc?view=revrev=516945
Log:
o little script to swap in the versions, until the site plugin can do it, this
will do. i'm tired of changing N
Yes, I can add the override model option in; I'm fairly busy presently, but
I can hopefully have something out in the next day or two.
Patrick
On 3/12/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 11 Mar 07, at 4:02 PM 11 Mar 07, Ralph Goers wrote:
Jason,
Well, I view the behavior of
On 12 Mar 07, at 2:23 AM 12 Mar 07, Kenney Westerhof wrote:
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1 will break more
than just surefire.
I certainly do the
On 12 Mar 07, at 6:15 AM 12 Mar 07, Jerome Lacoste wrote:
On 3/12/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
I think we should require the hiding of p-u 1.4.1 in 2.0.6, or let
it still use 1.1. All previous releases (except for beta releases)
use p-u 1.1. I'm afraid exposing p-u 1.4.1
I stumbled upon this issue over the weekend. If you are using the trunk
version from svn of the Checkstyle plugin, you cannot build the site for
any of our own plugins. I managed to work around it by explicitly
specifying maven-checkstyle-plugin version 2.1 temporarily in the pom. I
got the
Arnaud HERITIER wrote:
On 3/5/07, Brett Porter [EMAIL PROTECTED] wrote:
On 04/03/2007, at 4:05 PM, Dennis Lundberg wrote:
I found a couple of other bugs while testing, that I also fixed. I
feel pretty much done now. Snapshots have been deployed so that'll
give it some testing.
cool,
Dennis,
On Monday 12 March 2007 12:04, Dennis Lundberg wrote:
I stumbled upon this issue over the weekend. If you are using the trunk
version from svn of the Checkstyle plugin, you cannot build the site for
any of our own plugins. I managed to work around it by explicitly
specifying
I think what he is saying is that plugins out there may declare a newer
version of p-u (like mdep) that tested to work with that version ok (so
we thought) because it was really using the mvn core version. If
suddenly you allow plugins to use their own declared versions, they may
suddenly not
As you probably saw on the commit list, I did a bunch of commits for PMD
over the weekend. At this point, there is only one remaining issue open
for 2.2. (MPMD-41) To fix that completely, I need part of the objectweb
m2 repository synced to central. (asm/**/*)I've included the
current
+1. I've been running a snapshot rev from around sept, an official
version would be handy.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Monday, March 12, 2007 1:17 PM
To: dev@maven.apache.org
Subject: PMD plugin remaining issues...
As you probably saw on the
On 12 Mar 07, at 10:06 AM 12 Mar 07, Brian E. Fox wrote:
I think what he is saying is that plugins out there may declare a
newer
version of p-u (like mdep) that tested to work with that version ok
(so
we thought) because it was really using the mvn core version. If
suddenly you allow
should download.apt be removed from svn if it is generated?
On 12/03/2007, at 3:29 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Mon Mar 12 15:29:43 2007
New Revision: 517432
URL: http://svn.apache.org/viewvc?view=revrev=517432
Log:
o fix the generation script and encourage is spelt like
I wonder if this is an OS thing? I've heard that before, but when I
experimented with dependency:build-classpath, it was always ordered the
same.
-Original Message-
From: Jagan Padmanabha Pillai -X (jpadmana - Insight Solutions, Inc. at
Cisco) [mailto:[EMAIL PROTECTED]
Sent: Monday,
On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote:
should download.apt be removed from svn if it is generated?
Probably better to leave it there as people updating might forget to
generate it and deploy the site and then we'll end up with an empty
page. We can just nuke it when
On 12/03/2007, at 4:03 PM, Jason van Zyl wrote:
On 12 Mar 07, at 3:31 PM 12 Mar 07, Brett Porter wrote:
should download.apt be removed from svn if it is generated?
Probably better to leave it there as people updating might forget
to generate it and deploy the site and then we'll end up
Hi,
I didn't get an answer from the maven users alias. Could someone here
answer this.
Maven classpath generation seems not to follow any order. Shouldn't it
use the same order depedencies are mentioned in the pom file.
Somewhere I read Maven 2.0.5 fixed this issue, but when I tested it
There are some initiatives like Apache Felix about repackaging
libraries from the maven repository until projects themselves include
the OSGi manifest.
It makes sense in the meantime to have a Maven repo with same
structure but with OSGi bundles. This repo would be temporal and
things could
Is this going to result in a copy of all the artifacts with added
bundled metadata?
Will the structure will be same? Just wondering if the bundles should
just be included in the main repository with a classifier.
- Brett
On 12/03/2007, at 4:46 PM, Carlos Sanchez wrote:
There are some
I'd like to release maven-dependency-plugin:2.0-alpha-2
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug
in-2.0-alpha-2/
Staged at:
http://people.apache.org/~brianf/staging-repository
Changes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13137styleName
I'm seeing test failures in maven-source-plugin. Anyone else?
On Windows w/ Maven 2.0.5:
Failed tests:
testProject003(org.apache.maven.plugin.source.SourceJarMojoTest)
testProject007(org.apache.maven.plugin.source.SourceJarMojoTest)
Interesting...
http://people.apache.org/~wsmoak/maven/archiva/r517480-proxying-index-page.jpg
That's Archiva running on localhost, proxying central, and when I visit
http://localhost:9091/archiva/repository/myrepo/org/apache/maven/plugins/maven-dependency-plugin
I see the index page from central
Good day to you, Wendy,
On Windows XP, Maven 2.0.5, maven-source-plugin -r517268 builds fine
Cheers,
Franz
On 3/12/07, Wendy Smoak [EMAIL PROTECTED] wrote:
I'm seeing test failures in maven-source-plugin. Anyone else?
On Windows w/ Maven 2.0.5:
Failed tests:
http://maven.apache.org/developers/maven-eclipse-codestyle.xml
seems to be out of date ( the throws, extend, etc do not split )
Do we have another official one?
Thanks
-D
+1
On 10/03/2007, at 3:25 PM, Dennis Lundberg wrote:
Hi,
Trying this vote once more. This time with staging.
This release is a preparation for a new release of the maven-plugin-
plugin.
Changes:
- Add support for new annotations: @since for mojos and
@implementation
for parameters
-
+1
On 10/03/2007, at 3:21 PM, Dennis Lundberg wrote:
Hi,
Trying this vote once more. This with staging.
This release is a preparation for a release of the maven-one-plugin.
The issues that have been resolved can be seen in JIRA:
http://jira.codehaus.org/browse/MNG-2320
46 matches
Mail list logo
