On 22/05/2008, at 2:55 PM, Jason Dillon wrote:
Um, why would you want to only support http?
I wasn't suggesting that, I was just asking Jason (van Zyl) if the
survey was related to such a proposal he had made in the past.
--jason
On May 21, 2008, at 2:30 PM, Brett Porter wrote:
Hi J
On 22/05/2008, at 2:48 PM, Jason van Zyl wrote:
On 21-May-08, at 9:23 PM, Barrie Treloar wrote:
On Thu, May 22, 2008 at 1:06 PM, Jason van Zyl <[EMAIL PROTECTED]>
wrote:
It's not very complicated what we discussed. Essentially it's
artifactId =
symbolic bundle id because you'll never be
Um, why would you want to only support http?
--jason
On May 21, 2008, at 2:30 PM, Brett Porter wrote:
Hi Jason,
Is this related to your previous suggestion that we should only
support HTTP in Maven 2.1, or is there some other objective in mind?
Thanks,
Brett
2008/5/21 Jason van Zyl <[EMAIL
Mostly using http or https, though for the Geronimo TCK builds we are
using sftp for a private repository... mostly because it was less
work/infrastructure to setup https and than it was to re-use the
existing ssh channels.
The Geronimo build also use the file protocol internally to hook up
some p
On 21-May-08, at 9:23 PM, Barrie Treloar wrote:
On Thu, May 22, 2008 at 1:06 PM, Jason van Zyl <[EMAIL PROTECTED]>
wrote:
It's not very complicated what we discussed. Essentially it's
artifactId =
symbolic bundle id because you'll never be able to derive the
artifactId/groupId pair from a s
ping!
2008/5/19, Vincent Siveton <[EMAIL PROTECTED]>:
> Hi,
>
> We solved 13 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11124&styleName=Html&version=13504
>
> There are still a 0 of issues left in JIRA, yes 0, thanks Benjamin! :) :
>
> http://jira.codehaus.org/sec
2008/5/22, Barrie Treloar <[EMAIL PROTECTED]>:
> On Thu, May 22, 2008 at 1:06 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > It's not very complicated what we discussed. Essentially it's artifactId =
> > symbolic bundle id because you'll never be able to derive the
> > artifactId/groupId pair
On Thu, May 22, 2008 at 1:06 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> It's not very complicated what we discussed. Essentially it's artifactId =
> symbolic bundle id because you'll never be able to derive the
> artifactId/groupId pair from a symbolic bundle id because you don't know
> where t
Hi,
According the Doxia release process [1], I would like to release Maven
Doxia Tools 1.0.
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=11761&sorter/order=DESC&sorter/field=priority&resolution=-1&component=13263
St
On 21-May-08, at 8:23 PM, Barrie Treloar wrote:
On Thu, May 22, 2008 at 12:17 PM, Vincent Siveton
<[EMAIL PROTECTED]> wrote:
Hi Arnaud and others,
What is the "official" Eclipse repo layout? According [1] and [2],
[1]
seems the official. What others thinks?
Jason was meant to get back t
On Thu, May 22, 2008 at 12:17 PM, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> Hi Arnaud and others,
>
> What is the "official" Eclipse repo layout? According [1] and [2], [1]
> seems the official. What others thinks?
Jason was meant to get back to the list about this.
I haven't noticed it yet, b
That's what I was referring to.
On 22/05/2008, at 10:25 AM, Brian E. Fox wrote:
I thought Mark already started this and/or has a proposal on the wiki.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] On Behalf Of Brett
Porter
Sent: Wednesday, May 21, 2008 8:11 PM
To: Mav
I believe it's the latter.
This is very reminiscent of the scenario encountered in NMaven - it
seems it makes most sense to specify it in the Maven using the first
format, but that the repository layout should use the fully qualified
name for the file itself.
Maybe a different repo layout
Hi Arnaud and others,
What is the "official" Eclipse repo layout? According [1] and [2], [1]
seems the official. What others thinks?
For instance, with [1]
org.eclipse.equinox
app
and with [2]
org.eclipse.equinox
org.eclipse.equinox.app
Cheers,
Vincent
[1] mvn eclipse:to-maven
http://
(Fixed the parent pom version so the source jars get the correct
NOTICE/LICENSE things)
The Shade plugin has had a bunch of bugs fixed and other improvements
that should be pushed out to the users:
** Bug
* [MSHADE-23] - ${basedir} is wrong after running shade plugin
* [MSHADE-24] - Use
Due to the issues Vincent discovered, I'm withdrawing this. I'll
restage new versions shortly and restart the vote.
Dan
On May 21, 2008, at 1:59 PM, Daniel Kulp wrote:
The Shade plugin has had a bunch of bugs fixed and other
improvements that should be pushed out to the users:
**
I thought Mark already started this and/or has a proposal on the wiki.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] On Behalf Of Brett
Porter
Sent: Wednesday, May 21, 2008 8:11 PM
To: Maven Developers List
Subject: Re: dependency version conflict resolution
Hi John,
I
Hi John,
I don't think there's any objection to implementing this strategy -
however it's something that needs to be done in a pluggable way so
that current build behaviour doesn't change. This has a few
dependencies on other work in the core.
Some people who are interested have contribut
-1 since parent is maven-plugins:10 so NOTICE and LICENSE are not
present in maven-shade-plugin-1.1-sources.jar\META-INF
Cheers,
Vincent
2008/5/21, Daniel Kulp <[EMAIL PROTECTED]>:
>
> The Shade plugin has had a bunch of bugs fixed and other improvements that
> should be pushed out to the users
+1
Vincent
2008/5/21, Daniel Kulp <[EMAIL PROTECTED]>:
>
> The PMD plugin has had a bunch of bugs fixed and and other improvements
> that should be pushed out to the users:
>
>
> ** Bug
> * [MPMD-61] - When running build using "-f /pom.xml" the site
> is stored in working directory instead of
A new goal would be fine with me. When I looked into implementing it, I saw
that the changes could be pretty significant, like you said. That's why I
brought it up here before I start working on a patch.
Maybe it could be something like this to clarify between parent parent pom and
dependent
I'm new to list list so I apologize if this has been beaten to death
before, but I'd like to propose a change to the version conflict
resolution strategy that Maven uses. It's a combination of the
current "nearest version" strategy and a "highest version" strategy.
There are two cases:
1. When an
I personally find that tree very hard to understand. Again the scope of
dependency:tree is to show where the dependencies come from, not to show
the full inheritance of all of them. It sounds like what you want is a
new goal somewhere, either dependency or help to show the inheritance,
but I don't
Just as an example, if I run "mvn dependency:tree" on the maven jar plugin, I
currently see the dependency on maven-project.
[INFO] org.apache.maven.plugins:maven-jar-plugin:maven-plugin:2.3-SNAPSHOT
[INFO] +- org.apache.maven:maven-project:jar:2.0.7:compile
I would like to also see the parents
It shows the dependencies that are inherited, but it doesn't show the poms
themselves. If I run a build and see that there is a pom project being pulled
in, either by watching the command line or by looking in the local repository,
it's sometimes not obvious why that parent is being downloaded,
But the tree view is showing the dependency inheritance. Each one of
those dependencies may have one or more parent poms, I don't see what
this adds, nor how to show it any more as a tree.
-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 2:44 PM
T
I just want the parent poms to print in the output. Both in the tree view and
in the list generated by resolve.
So you would include things like:
org.apache.maven.plugins:maven-plugins:pom:12-SNAPSHOT:compile
Brian E. Fox wrote:
Adding it to resolve doesn't actually do anything since it will
Adding it to resolve doesn't actually do anything since it will already
be resolved. Can you provide an example of what you expect the output to
look like?
-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 2:31 PM
To: Maven Developers List
Subject:
If they are not dependencies of the project, then what are they? They do have
some relation to the project because they are needed in order to build, so I'm
just wondering where they fit in. Would it be reasonable to add a parameter to
the dependency plugin's resolve and tree goals to also inc
The PMD plugin has had a bunch of bugs fixed and and other
improvements that should be pushed out to the users:
** Bug
* [MPMD-61] - When running build using "-f /pom.xml"
the site is stored in working directory instead of project directory
* [MPMD-70] - Move hard-coded strings to resou
The Shade plugin has had a bunch of bugs fixed and other improvements
that should be pushed out to the users:
** Bug
* [MSHADE-23] - ${basedir} is wrong after running shade plugin
* [MSHADE-24] - Use proper file encoding when generating dependency
reduced POM
* [MSHADE-25] - Use proper enco
Both of those goals require Maven to do the dependency resolution, which
means the parent poms will already be resolved at that point. Strictly
speaking, the parents are not dependencies of the projects as we are
looking only at binary artifacts. Getting the parent poms is out of the
scope of those
I noticed that the dependency plugin currently does not include parent poms when
generating the dependency tree (MDEP-167) or when calling dependency:resolve.
Is the exclusion of the parent poms by design or is this something that just
hasn't been implemented yet? I would like to have a way t
On 22/05/2008, at 1:28 AM, Jason van Zyl wrote:
Are you going to roll this back? No one can stage anything until you
do.
setMaven 2.0.8 is way easier than setMaven 2.0.10 (given it's not
released yet :)
Apologies for the inconvenience, all.
- Brett
On 19-May-08, at 2:50 PM, Brett Po
Rolling it back would have to mean rolling the webdav back out of the
core as well. (that's what started this whole chain)
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 11:28 AM
To: Maven Developers List
Subject: Re: stage:copy ClassCastExc
Are you going to roll this back? No one can stage anything until you do.
On 19-May-08, at 2:50 PM, Brett Porter wrote:
On 20/05/2008, at 7:34 AM, Jason van Zyl wrote:
We have been releasing significantly faster with the last couple
releases, and if Wagon remains compatible why would you ne
Hi there,
I'd like to attempt to release Maven Runtime 1.0-alpha-1 again. The
changes since the last vote are:
- Upgraded to Java 5
- Sped up tests
- Added site documentation and reports
- Tidied code and Javadoc
Staging repo:
http://people.apache.org/~markh/staging-repo/
Staging site (not yet
On 21-May-08, at 8:07 AM, David Jencks wrote:
In particular, could you compare in detail this relaxng method and
the similar xml schema approach using substitution groups and
abstract schema types? (note that the substitution group part of
this is unnecessary but results in easier to read
Thanks, you should update its category so it shows up in the Maven
Technologies group list.
--jason
On May 21, 2008, at 10:09 PM, Brett Porter wrote:
MARTIFACT
On 22/05/2008, at 1:07 AM, Jason Dillon wrote:
I've got a patch waiting which adds type information for collection
bits it uses
Please :-) Sun is too bright, bring on the shade.
--jason
On May 21, 2008, at 10:07 PM, Jason van Zyl wrote:
I think if that many issues are resolved then release it. Can always
do another release.
On 20-May-08, at 11:39 AM, Daniel Kulp wrote:
A bunch of bugs have been fixed in the sha
Hi, I've finally gotten around to integration maven-artifact w/
GShell... and I noticed that when resolving artifacts it tends to
prefer the repositories in dependency poms? Maybe its not a maven-
artifact thingy, but a maven-project thingy as I'm re-using the Maven
metadata source thingy.
MARTIFACT
On 22/05/2008, at 1:07 AM, Jason Dillon wrote:
I've got a patch waiting which adds type information for collection
bits it uses... dunno where to post it.
--jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For ad
In particular, could you compare in detail this relaxng method and the
similar xml schema approach using substitution groups and abstract
schema types? (note that the substitution group part of this is
unnecessary but results in easier to read xml)? After studying your
blog post I don't s
I've got a patch waiting which adds type information for collection
bits it uses... dunno where to post it.
--jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think if that many issues are resolved then release it. Can always
do another release.
On 20-May-08, at 11:39 AM, Daniel Kulp wrote:
A bunch of bugs have been fixed in the shade plugin recently. I'm
thinking of doing a 1.1 release shortly. Does anyone have other
things to add int
Bryon,
How would you compare this with a method like this using XML Schema.
I'm not a huge fan of XSD, but there is a lot of tooling for XSD
especially in IDEs and that would be something we have to consider. Do
you actually use this method you describe in a production system, or
just a t
Try having a look at this example:
https://svn.codehaus.org/mojo/trunk/sandbox/fit-maven-plugin/src/main/java/org/codehaus/mojo/fit/
Cheers
Claudio Ranieri wrote:
Hi
I am trying to create a maven plugin to jboss wsconsume, but I have a problem
with classloader in plugin.
My plugin is based i
On 21-May-08, at 12:30 AM, Brett Porter wrote:
Hi Jason,
Is this related to your previous suggestion that we should only
support HTTP in Maven 2.1, or is there some other objective in mind?
I want to first know what users are doing before suggesting anything.
Thanks,
Brett
2008/5/21 Jaso
Anyone?
I want help the open source community, but I have this problem with classloader.
-Mensagem original-
De: Claudio Ranieri [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 20 de maio de 2008 10:07
Para: dev@maven.apache.org
Assunto: Problem with classloader in maven plugin
Hi
I a
Welcome Dan.
Arnaud
On Wed, May 21, 2008 at 2:44 AM, Jesse McConnell <[EMAIL PROTECTED]>
wrote:
> welcome!
>
> On Tue, May 20, 2008 at 7:13 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > The Maven PMC has voted to add Daniel Kulp to the PMC.
> >
> > Welcome, Dan!
> >
> > Cheers,
> > Brett
> >
>
Hi Jason,
Is this related to your previous suggestion that we should only
support HTTP in Maven 2.1, or is there some other objective in mind?
Thanks,
Brett
2008/5/21 Jason van Zyl <[EMAIL PROTECTED]>:
> Hi,
>
> I'm just trying to get some data on what protocol is used to retrieve
> artifacts. T
51 matches
Mail list logo
