I have some questions about specific closed issues that might warrant
reopening:
On 05/06/2007, at 3:05 PM, Jason van Zyl (JIRA) wrote:
Jason van Zyl closed MNG-5.
---
Resolution: Fixed
pretty resources addition
-
Was this really implem
On 06/06/2007, at 8:28 AM, Mark Hobson wrote:
On 04/06/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
Hi there,
Is the ArtifactFilter passed into the ArtifactCollector.collect
methods meant to be applied before calls to the ResolutionListeners?
Currently it appears to disregard the filter whils
(Getting annoyed by everyone replying to each other across 3 threads,
so picking this one to move forward from)
On 06/06/2007, at 5:29 AM, Jason van Zyl wrote:
Here is my reasoning as the Embedder as the only form we should be
exposing in the short term (the emphasis being on short term)
h
On 06/06/2007, at 2:06 PM, Jason van Zyl wrote:
Is this different/related to the design paper you were working on?
As I've said before, I'm interested in collaborating on this, and
would like to see it posted somewhere.
No, he started on this prior to what I started. I have the
underly
On Mon, 2007-06-04 at 21:27 +0800, Gav wrote:
>
> > -Original Message-
> > From: Vincent Siveton [mailto:[EMAIL PROTECTED]
> > Sent: Monday, 4 June 2007 8:27 PM
> > To: [EMAIL PROTECTED]
> > Cc: dev@maven.apache.org
> > Subject: Forrestdoc and Maven JXR
> >
> > Hi,
> >
> > The Maven
+1
On 6/5/07, Arik Kfir <[EMAIL PROTECTED]> wrote:
If I recall correctly, it only happens if you invoke "idea:*" on an inner
module, rather than the aggregating module (pom).
Personally I don't think it's much of an issue; one usually wants to
generate a project for the entire project, rather
On 5 Jun 07, at 11:33 PM 5 Jun 07, Brett Porter wrote:
On 06/06/2007, at 5:48 AM, Jason van Zyl wrote:
John has started an API cleanup for artifact resolution and one is
slated for maven-project but the second we promote these we are
really bound to support them and the one that are there
On 5 Jun 07, at 11:29 PM 5 Jun 07, Brett Porter wrote:
On 06/06/2007, at 1:24 PM, Jason van Zyl wrote:
Ok, we have a problem with 2.0.6/2.0.7-SNAPSHOT with the surefire
plugin when there are xml classes used in tests. I'm trying this
with Russ Tremain at Sun with the JBI components projec
On 06/06/2007, at 5:48 AM, Jason van Zyl wrote:
John has started an API cleanup for artifact resolution and one is
slated for maven-project but the second we promote these we are
really bound to support them and the one that are there now are
unsupportable.
Is this different/related to t
On 5 Jun 07, at 10:55 PM 5 Jun 07, Carlos Sanchez wrote:
and btw this is the thread where I brought up these changes time ago
http://www.nabble.com/Avoiding-duplicate-packages-in-different-
modules-tf3557533s177.html#a9933847
And as per usual anything not put in the wiki in the design doc
On 5 Jun 07, at 10:31 PM 5 Jun 07, Carlos Sanchez wrote:
people use what they need, if they want just the IoC container they
don't add all the required dependencies of the whole spring
Our APIs are there and we have to keep backwards compatibility anyway.
In 2.0.x that's perfectly fine. In
On 06/06/2007, at 1:24 PM, Jason van Zyl wrote:
Ok, we have a problem with 2.0.6/2.0.7-SNAPSHOT with the surefire
plugin when there are xml classes used in tests. I'm trying this
with Russ Tremain at Sun with the JBI components project.
What version of surefire is that using?
2.3.1-SNAPSH
On 5 Jun 07, at 10:27 PM 5 Jun 07, Carlos Sanchez wrote:
On 6/5/07, John Casey <[EMAIL PROTECTED]> wrote:
I don't think we should be promoting the current APIs for public
consumption. They're a friggin mess. But, we could create some nice
facade classes in each of the main (artifact, project,
On 5 Jun 07, at 10:23 PM 5 Jun 07, Carlos Sanchez wrote:
there's many tools, libraries, etc out there that use the libraries, i
don't see why we have to limit this use in any way
I don't think that's the case. It's primarily the embedder in the 17
cases of IDE integration and products tha
Ok, we have a problem with 2.0.6/2.0.7-SNAPSHOT with the surefire
plugin when there are xml classes used in tests. I'm trying this with
Russ Tremain at Sun with the JBI components project.
I'm going to get him to try a snapshot version of surefire.
Brett, is there a new snapshot of surefire
and btw this is the thread where I brought up these changes time ago
http://www.nabble.com/Avoiding-duplicate-packages-in-different-modules-tf3557533s177.html#a9933847
On 6/5/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 5 Jun 07, at 3
That's a separate discussion, if you want to release 2.1 tomorrow I'm
all for it, but I don't see how my changes refactor everything. I kept
the old classes deprecated and they extend the new ones so behavior is
exactly the same, of all the changes in trunk this is not the riskiest
one by far. But
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 5 Jun 07, at 3:36 PM 5 Jun 07, Carlos Sanchez wrote:
> You are mixing again best practices in package naming with the
> embedder use. My changes were targeting the first.
>
> Regarding the embedder I don't agree at all, for the same reason
On 6/5/07, John Casey <[EMAIL PROTECTED]> wrote:
I don't think we should be promoting the current APIs for public
consumption. They're a friggin mess. But, we could create some nice
facade classes in each of the main (artifact, project, embedder -
which already has them) subsystem projects, and p
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 4 Jun 07, at 9:13 PM 4 Jun 07, Brett Porter wrote:
>
> On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
>
>> I noticed the issue with duplicated packages while playing with OSGi
>> but is not directly related.
>> The fact that we have same
(moved to dev@)
Jason,
Is there any way we can get this text into the issue submission form
itself? I think people need the just in time reminder.
- Brett
On 06/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
We only have this:
http://maven.apache.org/guides/development/guide-m2-
developmen
I agree. If we try to refactor everything now, it just means longer term before
2.1 can come out. Committing to a public façade for future compatibility and
abstraction from internals is the way to go.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June
Now that maven-release-plugin-2.0-beta-6 has gone out is it possible to
get this patch applied or at least discuss it? I have a patched version
of 2.0-beta-6 in house that has been making use of the extra release
phase without any problems and it seem like a good addition to the
plugin's behaviour.
On 6/5/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
So when I republished the latest docs from svn trunk for the site-plugin
into /plugins/maven-site-plugin/ I did wrong?
I wouldn't go that far. :) I didn't check the site closely, I just
remember that the site plugin was the one I was exper
Wendy Smoak wrote:
[moved to [EMAIL PROTECTED]
On 6/5/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
That page should not exist. Someone seems to have published an old
version of the site. I'll republish it.
Probably me... after some discussion, we decided that the
/plugins/maven-xzy-plugin
On 04/06/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
Hi there,
Is the ArtifactFilter passed into the ArtifactCollector.collect
methods meant to be applied before calls to the ResolutionListeners?
Currently it appears to disregard the filter whilst recursing and then
apply it only when calculatin
[moved to [EMAIL PROTECTED]
On 6/5/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
That page should not exist. Someone seems to have published an old
version of the site. I'll republish it.
Probably me... after some discussion, we decided that the
/plugins/maven-xzy-plugin docs should be for t
Second is the assumption that "GET" requests are not webdav requests.
Some WebDav client implementations improperly use the "GET" request to
obtain file/folder information. (they should be using the various
xml/propget requests to obtain that list.)
We could likely make it work, but in the pr
On 5 Jun 07, at 3:44 PM 5 Jun 07, John Casey wrote:
I don't think we should be promoting the current APIs for public
consumption. They're a friggin mess. But, we could create some nice
facade classes in each of the main (artifact, project, embedder -
which already has them) subsystem proje
On 5 Jun 07, at 3:36 PM 5 Jun 07, Carlos Sanchez wrote:
You are mixing again best practices in package naming with the
embedder use. My changes were targeting the first.
Regarding the embedder I don't agree at all, for the same reason then
why don't we just put classes in a source folder and o
Splitting up this discussion ...
First is the "detection" of clients.
Archiva has to manage not only the artifact, but also the pom/model
version too.
Example:
A maven 2 client can request either of these format URLs.
http://machine.com/repository/internal/commons-lang/poms/commons-lang-2.1.po
I don't think we should be promoting the current APIs for public
consumption. They're a friggin mess. But, we could create some nice
facade classes in each of the main (artifact, project, embedder -
which already has them) subsystem projects, and promote the use of
those. The embedder shoul
You are mixing again best practices in package naming with the
embedder use. My changes were targeting the first.
Regarding the embedder I don't agree at all, for the same reason then
why don't we just put classes in a source folder and only one maven
project? plugins and any other tool choose wh
Here is my reasoning as the Embedder as the only form we should be
exposing in the short term (the emphasis being on short term)
http://docs.codehaus.org/display/MAVEN/The+Embedder+for+all+client+use
+in+2.1
On 4 Jun 07, at 9:01 PM 4 Jun 07, Carlos Sanchez wrote:
I got this lost between th
I agree. Any reason we can't use detection?
Also, any reason why the handler for downloading from the /
repository/ can't be this get servlet instead of dav servlet? We
probably don't want to add new ways to download from the repository
for the same reason we removed /proxy/. I realise you c
Right. The reason for not choosing to install by default is that you
end up with a "release" in your local repository which is not the
final one.
Perhaps the release plugin should install, but clean up the installed
artifacts afterwards. We seem to be seeing this problem a little more
gen
Mark Donszelmann wrote:
> Hi
>
> I am using an aggregate project such as:
>
> T
> -A
> -B
> -C
>
> where C and B have a dependency on A
> and A, B, C all use T as their parent pom.
>
> When I run "mvn install" the projects are run in the correct order: "T,
> A, B, C"
> and all works fine for le
The "/get/{implementation-id}/{layout-path}" is an interesting option.
Where would you place the target managed repository in such an URL ?
The only thing I don't like in this solution is that it doesn't work based
on an auto-detection of the requested format. I'd prefer the servlet to
search fo
Hi
I am using an aggregate project such as:
T
-A
-B
-C
where C and B have a dependency on A
and A, B, C all use T as their parent pom.
When I run "mvn install" the projects are run in the correct order:
"T, A, B, C"
and all works fine for lets say 3.3-SNAPSHOT.
When I now run "mvn release:
On 4 Jun 07, at 9:01 PM 4 Jun 07, Carlos Sanchez wrote:
I haven't changed in any way how things worked before, completely
backwards compatible, no changes to the embedder, no idea what are you
talking about.
The Maven functionality should be deployed as a single bundle. Things
like provid
On 4 Jun 07, at 9:13 PM 4 Jun 07, Brett Porter wrote:
On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
I noticed the issue with duplicated packages while playing with OSGi
but is not directly related.
The fact that we have same packages in different modules is just a
bad
practice, for arc
On 6/4/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
> I noticed the issue with duplicated packages while playing with OSGi
> but is not directly related.
> The fact that we have same packages in different modules is just a bad
> practice, for arc
They are ;-)
Just make sure you generate the project from the root module.
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 5 Jun 07, at 8:26 AM 5 Jun 07, Arik Kfir wrote:
> If I recall correctly, it only happens if you invoke "idea:*" on an
> inner
> module, rather than the aggregating
The following are the results of this vote.
+5 Binding Votes ( Jesse, Emmanuel, Wendy, Fabrice, and Myself)
+2 Non-binding Votes (Maria, and Nicolas)
The release is good to go.
I'll send another update when it has been completed.
- Joakim
Joakim Erdfelt wrote:
Archiva 1.0-alpha-1 was tagged a
I agrea. Simply adding support for converting legacy -> default requests
requires to patch the DavServer. Adding support for server-side relocation
requires even more.
A new layer between Dav servlet and the repository (and it's proxies) would
make things cleaner and extensible. Is there any draf
could you make that apache license?
then you can add it to issue
http://jira.codehaus.org/browse/PLXREDBACK-74
and I'll take a look-see, I have been kicking around different ways to
use ldap so it will be nice to see what you have :)
jesse
On 6/5/07, David Goemans <[EMAIL PROTECTED]> wrote:
On 5 Jun 07, at 8:26 AM 5 Jun 07, Arik Kfir wrote:
If I recall correctly, it only happens if you invoke "idea:*" on an
inner
module, rather than the aggregating module (pom).
Personally I don't think it's much of an issue; one usually wants to
generate a project for the entire project, rathe
I don't like hooking up the webdav interface into the dynamic artifact
serving.
I think we need to investigate the DASL layer idea in the Archiva
Roadmap, maybe move it up in priority.
http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap
- Joakim
nicolas de loof wrote:
I allready notice
+1
On 4 Jun 2007, at 23:04, Dennis Lundberg wrote:
Hi,
I'd like to release maven-idea-plugin 2.1. There are 12 issues
fixed in
this version and the last release was made over a year ago.
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?
projectId=11135&styleName=Html&versio
If I recall correctly, it only happens if you invoke "idea:*" on an inner
module, rather than the aggregating module (pom).
Personally I don't think it's much of an issue; one usually wants to
generate a project for the entire project, rather than just a single module.
But I'm interested to know
Hi,
I'm working on a merant Dimensions SCM SCM plugin. I kinda had it working
with the Dimensions CLI client.
Recently I tried upgrading the maven-scm-api dependency used by my plugin to
version 1.0. After some work this all compiles and installs fine.
But when I try running a mvn release:prepa
This is fixed in 2.1 if you generate the modules in a reactor build.
Stéphane
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
+1
Though I think one of the major issues it has which makes it somewhat
hard to use is that modules are link to JARs in the repository
instead of to each other. Th
+1
Though I think one of the major issues it has which makes it somewhat
hard to use is that modules are link to JARs in the repository
instead of to each other. The ${basedir}/target/classes and sources
should all be hooked up together.
On 5 Jun 07, at 3:11 AM 5 Jun 07, Stephane Nicoll w
Hi Kevin,
(See inside)
2007/3/24, Kevin Stembridge <[EMAIL PROTECTED]>:
Hi folks,
I'm getting an OutOfMemoryError when running mvn javadoc:javadoc in a
Java6 JVM. The same goal runs without error in Java5. My pom config and
console output are pasted below.
I tried adding a element to the plug
A big +1 !
Thanks,
Stéphane
On 6/5/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Hi,
I'd like to release maven-idea-plugin 2.1. There are 12 issues fixed in
this version and the last release was made over a year ago.
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=1
55 matches
Mail list logo
