Michael McCallum wrote:
On Wed, 13 Aug 2008 17:42:17 Ralph Goers wrote:
To be honest, even with this I'd still probably not use version ranges.
But I sure would like for Maven to be able to fail the build because two
artifacts need incompatible versions of the same thing.
it does if yo
On 12/08/2008, at 1:30 AM, Jason van Zyl wrote:
On 11-Aug-08, at 1:55 AM, Brett Porter wrote:
Hi,
The proposal in the "Versioning" thread brings us to having 3 main
development lines for Maven itself, and that has a couple of
consequences for how we develop that I wanted to explore sepa
> >
> > I have to disagree here: developers should not care what repositories
> > they have, or what dependency plugin shows them. They should, instead,
> > simply say what they want - and get it. That is why, imho, the core,
> > including dependency resolution, should be smarter :)
thats like sayi
On Wed, 13 Aug 2008 17:42:17 Ralph Goers wrote:
>
> To be honest, even with this I'd still probably not use version ranges.
> But I sure would like for Maven to be able to fail the build because two
> artifacts need incompatible versions of the same thing.
it does if you use version ranges
an
On Wed, Aug 13, 2008 at 7:34 AM, Oleg Gusakov
<[EMAIL PROTECTED]> wrote:
>
>
> Michael McCallum wrote:
>>
>> On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
>>
>>
>
> 2). I strongly feel that failing any explicit ranges, containing
> snapshots is a good thing. For instance, dependency
Michael McCallum wrote:
On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote:
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and
slots... http://www.gentoo.org/
http://devmanua
Michael McCallum wrote:
On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
2). I strongly feel that failing any explicit ranges, containing
snapshots is a good thing. For instance, dependency declaration
1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like
[1.2-SNAPSHOT,2.
On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote:
> Michael McCallum wrote:
> > To be well rounded we should consider other approaches to dependencies
> >
> > its worth having a look at how gentoo does versioning with ranges and
> > slots... http://www.gentoo.org/
> > http://devmanual.gentoo.org/gene
If there are descriptive commit messages on the branch, they get lost
in the merge, and the branch will get deleted at some poing. Is there
a JIRA issue or a discussion on the list that this goes with?
-Wendy
On Tue, Aug 12, 2008 at 10:09 PM, <[EMAIL PROTECTED]> wrote:
> Author: sisbell
> Date:
Oleg Gusakov wrote:
Ralph Goers wrote:
Oleg Gusakov wrote:
What do you think about snapshots in ranges? Or - better -
prohibiting snapshot in ranges.
I don't know. In a dev environment you might want the "latest",
whatever that is.
For me there is a code quality boundary between re
Ralph Goers wrote:
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and
slots...
http://www.gentoo.org/
http://devmanual.gentoo.org/general-concepts/dependencies/index.html
http
On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
> >> 2). I strongly feel that failing any explicit ranges, containing
> >> snapshots is a good thing. For instance, dependency declaration
> >> 1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like
> >> [1.2-SNAPSHOT,2.0) or [1.0,1
Michael McCallum wrote:
3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
2.1-alpha-1, etc
Should most definitely not inlude 2.1-alpha-1 consider this scenario...
module Z released as 2.X
a dependent module Y specifies X [2,3)
you now make a breaking change and release
Ralph Goers wrote:
Oleg Gusakov wrote:
What do you think about snapshots in ranges? Or - better -
prohibiting snapshot in ranges.
I don't know. In a dev environment you might want the "latest",
whatever that is.
For me there is a code quality boundary between release and snapshot,
an
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and slots...
http://www.gentoo.org/
http://devmanual.gentoo.org/general-concepts/dependencies/index.html
http://devmanual.gentoo.org/
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and slots...
http://www.gentoo.org/
http://devmanual.gentoo.org/general-concepts/dependencies/index.html
http://devmanual.gentoo.org/general-concepts/slotting/in
> 3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
> 2.1-alpha-1, etc
Should most definitely not inlude 2.1-alpha-1 consider this scenario...
module Z released as 2.X
a dependent module Y specifies X [2,3)
you now make a breaking change and release the alpha version of Z 3.0-al
On 13/08/2008, at 12:31 PM, Oleg Gusakov wrote:
Current implementation (let's call it 2.0) is promiscuous inside the
"dirty" dependency tree - all possible versions before conflict
resolution. But for plugins - the first plugin found wins. I would
say - we should be consistent and *treat p
On 13/08/2008, at 10:51 AM, Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard
definition of a "version range", so I took OSGi definition: OSGi
core specs 4.1, page 39 in April-2007 PDF available on OSGi site - http://osgi.org
.
Some interesting ramification
Oleg Gusakov wrote:
What do you think about snapshots in ranges? Or - better - prohibiting
snapshot in ranges.
I don't know. In a dev environment you might want the "latest", whatever
that is.
Ralph
-
To unsubscribe,
Igor Fedorenko wrote:
Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard
definition of a "version range", so I took OSGi definition: OSGi core
specs 4.1, page 39 in April-2007 PDF available on OSGi site -
http://osgi.org.
Some interesting ramifications for Ma
Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard definition
of a "version range", so I took OSGi definition: OSGi core specs 4.1,
page 39 in April-2007 PDF available on OSGi site - http://osgi.org.
Some interesting ramifications for Maven users:
1). Declaratio
>[Brian E. Fox wrote:]
>I think we can make room for some >IBM jdks.
Awesome.
Thanks Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Working on Mercury I faced the necessity to use some standard definition
of a "version range", so I took OSGi definition: OSGi core specs 4.1,
page 39 in April-2007 PDF available on OSGi site - http://osgi.org.
Some interesting ramifications for Maven users:
1). Declaration 1.2.3 means any ver
Can you give me the SVN URL for the build you want us to run and the
goals/options you use?
I will set it up in Hudson and add it to our community builds for
testing.
On 12-Aug-08, at 3:28 PM, Vincent Massol wrote:
Hi John,
Just tried it on XWiki and I get an error in a custom plugin tha
do you have a stack trace, and maybe some steps to reproduce?
Thanks,
-john
Vincent Massol wrote:
Hi John,
Just tried it on XWiki and I get an error in a custom plugin that looks
for dependencies in the project. The error I get is:
Caused by: org.apache.maven.plugin.MojoExecutionException:
I think we can make room for some IBM jdks.
-Original Message-
From: Timothy Reilly [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 12, 2008 6:37 PM
To: Maven Developers List
Subject: In summer, the sky is blue?
I wanted to try to faciliate maven testing on IBM jdk's.
To following on to
I wanted to try to faciliate maven testing on IBM jdk's.
To following on to the "In summer, the sun shines" with some questions
about the CI or IT server / grid:
> It will be running Vmware ESX and hosting many VMs
> to build out a Hudson grid of various os's in master-slave mode.
I've been co
Hi John,
Just tried it on XWiki and I get an error in a custom plugin that
looks for dependencies in the project. The error I get is:
Caused by: org.apache.maven.plugin.MojoExecutionException: Artifact
[com.xpn.xwiki.products:xwiki-enterprise-wiki] is not a dependency of
the project.
After one week, the result is:
a) UTF-8: 4 votes on user list + 2 previously on dev list
b) same as source: 2 votes on user list
1 vote for platform encoding
Default encoding for reports will be UTF-8.
Thanks for your participation.
Regards,
Hervé
Le mardi 05 août 2008, Hervé BOUTEMY a écrit
Okay, I've reopened MNG-3703 for this, since it's a different use case
the executed project left over from a forked lifecycle, which doesn't
have concrete values in its build section by the time the forking
(mojo|report) gets it. I've got it fixed on my localhost, but I'm going
to add another t
K, sounds good. Thanks,
-john
Jason van Zyl wrote:
On 12-Aug-08, at 10:59 AM, John Casey wrote:
I'm not entirely sure I understand what this configuration does. When
you say 'promote' you're talking about a process internal to Hudson
that allows us to use that RC in other Hudson builds, rig
Jason van Zyl wrote:
Mauro,
Here's the result here:
http://ci.sonatype.org/view/Community%20Test%20Projects/job/XSite/3/console
That seem fine?
That's fine but you need to check the actual content of the cobertura
report.
eg open xsite-core/target/site/cobertura/index.html and click on t
Jason van Zyl wrote:
Mauro,
Can I have your SVN coordinates and the goals you run to test and I will
set Pico up in Hudson for us to test.
https://svn.codehaus.org/picocontainer/java/2.x/trunk
The uber-build is executed by a simple mvn clean install.
This uber-build works now with 2.0.10
Hi there,
Has anyone got any objections to releasing the trunk of
maven-dependency-tree as 1.2? A stable release is required by
m2eclipse. If there are no objections then I'll start a vote.
Cheers,
Mark
-
To unsubscribe, e-ma
On 12-Aug-08, at 11:53 AM, Ralph Goers wrote:
Jason van Zyl wrote:
The Sonatype team is pleased to announce the Beta-5 release of our
Nexus Maven Repository Manager. This release brings the much
awaited role based security to the popular tool. You can find out
more about it here:
http
Jason van Zyl wrote:
The Sonatype team is pleased to announce the Beta-5 release of our
Nexus Maven Repository Manager. This release brings the much awaited
role based security to the popular tool. You can find out more about
it here:
http://blogs.sonatype.com/brian/2008/08/12/1218551235596
On 12-Aug-08, at 10:59 AM, John Casey wrote:
I'm not entirely sure I understand what this configuration does.
When you say 'promote' you're talking about a process internal to
Hudson that allows us to use that RC in other Hudson builds,
right? ...for instance, to test CXF on Hudson using t
I'm not entirely sure I understand what this configuration does. When
you say 'promote' you're talking about a process internal to Hudson that
allows us to use that RC in other Hudson builds, right? ...for instance,
to test CXF on Hudson using that promoted RC? It's not promoting in the
sense o
I've got the NPE fixed, but it took awhile to write an integration test
that would help verify it without requiring a Hudson instance. ;)
I'll work on the sources jar next, once the full IT run I just started
is finished.
Daniel Kulp wrote:
I'm testing with CXF trunk: (jdk 1.5)
https://svn.
The Sonatype team is pleased to announce the Beta-5 release of our
Nexus Maven Repository Manager. This release brings the much awaited
role based security to the popular tool. You can find out more about
it here:
http://blogs.sonatype.com/brian/2008/08/12/1218551235596.html
Thanks,
Jason
Mauro,
Here's the result here:
http://ci.sonatype.org/view/Community%20Test%20Projects/job/XSite/3/console
That seem fine?
On 12-Aug-08, at 10:10 AM, Jason van Zyl wrote:
Mauro,
Can I have your SVN coordinates and the goals you run to test and I
will set Pico up in Hudson for us to test.
Ok, it's setup here:
http://ci.sonatype.org/view/Community%20Test%20Projects/job/XSite/
On 12-Aug-08, at 10:07 AM, Mauro Talevi wrote:
mvn clean install -Preporting
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonaty
Mauro,
Can I have your SVN coordinates and the goals you run to test and I
will set Pico up in Hudson for us to test.
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
-
John Casey wrote:
Hi Daniel, Mauro,
In either of these cases, can anyone give me some specific steps (and
the project SVN URL, if possible) to reproduce the problem? I tried
running 'mvn clean source:jar' last night on maven-project and
maven-model, but apparently that's too simplistic to rep
John,
Now in the 2.0.x panel there is now a way to do an RC, promote it, and
then use it in the community test projects.
So the process would be:
1. Build the RC
http://ci.sonatype.org/view/Maven%202.0.x/job/Maven%202.0.10-RC/
2. If that's cool, then promote the distribution
http://ci.sonat
I'm testing with CXF trunk: (jdk 1.5)
https://svn.apache.org/repos/asf/cxf/trunk/
I think the NPE is hit with:
mvn install -Peverything,nochecks
The sources jar issue I hit with:
mvn install -Pdeploy,everything,nochecks -Dmaven.test.skip.exec=true
and then checking the source jars that were gen
If we can collect those projects that would be great. If people want
to give us builds to test then let's collect them here:
http://ci.sonatype.org/view/Community%20Test%20Projects/
I loaded up CXF as Dan suggested, so let's some other project in there.
I can now build the RC and then promote
Hi Daniel, Mauro,
In either of these cases, can anyone give me some specific steps (and
the project SVN URL, if possible) to reproduce the problem? I tried
running 'mvn clean source:jar' last night on maven-project and
maven-model, but apparently that's too simplistic to reproduce the
problem
On Tue, 2008-08-12 at 17:59 +1000, Brett Porter wrote:
> Any other opinions?
>
> On 08/08/2008, at 6:26 PM, Mark Hobson wrote:
>
> > 2008/8/8 Brett Porter <[EMAIL PROTECTED]>:
> >> I was poking back through the archives for a couple of things
> >> related to
> >> Maven core and was having trou
Hi,
2008/8/12 Brett Porter <[EMAIL PROTECTED]>:
> Any other opinions?
+0 and agree with Paul or Arnaud comments.
Cheers,
Vincent
> On 08/08/2008, at 6:26 PM, Mark Hobson wrote:
>
>> 2008/8/8 Brett Porter <[EMAIL PROTECTED]>:
>>>
>>> I was poking back through the archives for a couple of things
Daniel Kulp wrote:
John,
Performance is a bit better, but in a multi-project reactor build, the source
jars are now all "wrong". None of the source ends up in the jars. Just
the "extra" things from the remote-resources.
Yes - I can confirm that. In fact, another symptom of this is run
Hi,
The last release of maven-scm is now 14 months old.
I'd like to release maven-scm 1.1 which include two new providers git
and accurev and fix some issues.
We solved 26 issues :
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13984&styleName=Html&projectId=10527&Create=Create
Staging
Hi,
Same opinion as Arnaud.
--
Olivier
2008/8/12 Arnaud HERITIER <[EMAIL PROTECTED]>:
> +0
> In both cases I'll subscribe to these mailing lists and will continue to
> read them.
> Perhaps it can ease rules in mail clients
>
> Arnaud
>
> On Tue, Aug 12, 2008 at 9:59 AM, Brett Porter <[EMAIL PROTE
Brett Porter wrote:
Any other opinions?
I can easily put mails from different lists back into the same post
folder if I want but splitting mails from the same list according to
their topic is more tricky ;-) So I am +1 for the split.
If this is made in time, we could update our parent POMs
+0
In both cases I'll subscribe to these mailing lists and will continue to
read them.
Perhaps it can ease rules in mail clients
Arnaud
On Tue, Aug 12, 2008 at 9:59 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> Any other opinions?
>
>
> On 08/08/2008, at 6:26 PM, Mark Hobson wrote:
>
> 2008/8/8
Any other opinions?
On 08/08/2008, at 6:26 PM, Mark Hobson wrote:
2008/8/8 Brett Porter <[EMAIL PROTECTED]>:
I was poking back through the archives for a couple of things
related to
Maven core and was having trouble since it was drowned out in plugin
development discussion and votes.
Consid
57 matches
Mail list logo
