+1
-Lukas
Dennis Lundberg wrote:
Hi,
We solved 46+1 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&version=16829
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=17501
There are still a couple of issues left in
That's correct, but you'll then have to query the content handler object for
it's currently running port.
I'm going to keep pimping out this solution I built for some clients and
open sourced a while back.
In one project I have an api for starting up a jetty application server
either off of the ec
On 31/07/2011, at 8:57 AM, Jason van Zyl wrote:
> Ok, I'll pick up from Ralph's discussion.
>
> On Jul 29, 2011, at 1:16 PM, Brett Porter wrote:
>
>> -0
>>
>> I don't like it, but I'm not the one doing the work. I'd accept it if
>> there's no better way to get the problems fixed for whoever i
On 31/07/2011, at 4:51 AM, Benson Margulies wrote:
> Trading
> more or less insulting public emails with Jason does not qualify under
> that rubric, in my opinion.
Yes, personal attacks have no place here. Coming back after the weekend, I was
disappointed with the tone of the thread. Everyone n
On 31/07/2011, at 6:04 AM, Benson Margulies wrote:
> Kristian,
>
> legal-discuss is a public list, with public archives. You can go read
> these remarks for yourself in the archive. I apologize for assuming
> that you or anyone else didn't know that. Yes I am a member, but Ralph
> and I are not
What you are suggesting here is something I've been advocating for the last
several years - adding "provides" and "requires" to poms to indicate versions
of things they require that are more granular than the jar. In the example
below the driver might support several JDBC versions. Specifying ju
2011/7/31 Dennis Lundberg :
> Hi
>
> While going through our jobs in Jenkins [1] I found a couple of jobs
> that I see no point in having there anymore. These are:
>
> 1 core-integration-testing
> We have other builds for this, and this one has no SCM configured
>
> 2 doxia-trunks
> We have separ
By popular request, I've expanded
https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
(and changed its name). It now reflects our recent reflections on
attributes, plus some thoughts on namespaces.
Please break out your darts and start throwing.
--
Hi
While going through our jobs in Jenkins [1] I found a couple of jobs
that I see no point in having there anymore. These are:
1 core-integration-testing
We have other builds for this, and this one has no SCM configured
2 doxia-trunks
We have separate build for doxia, doxia-sitetools and do
It turns out that someone had accidently arranged for several projects
to share a workspace, and then to use a private maven repo inside that
workspace, with the predicable disasterous consequences.
However, I'm sure the Sonatype config will be helpful.
On Sun, Jul 31, 2011 at 4:41 PM, Jason van
Hi
Just a heads up that those of you that are subscribed to
notificati...@maven.apache.org will be seeing a lot more e-mails coming
your way from Jenkins.
I'm going over the configurations for our projects in Jenkins, one
parameter at a time. This time I've enabled e-mail notifications for
pretty
Hi Jason!
The bugs are fixed already. What we now see are _real_ bugs and they should
fail in your CI system too (can also be reproduced locally).
LieGrue,
strub
--- On Sun, 7/31/11, Jason van Zyl wrote:
> From: Jason van Zyl
> Subject: Re: non-reproducible issues on CI
> To: "Maven Develope
I will re-expose the Sonatype Hudson instances as a point of reference. They
have been running successfully since you guys flipped over to Jenkins. Our
setup can at least serve as some guidance as to what might be wrong with your
setup.
On Jul 31, 2011, at 10:58 AM, Mark Struberg wrote:
> Hi B
afaik since always. standard socket.open(port) behaviour when port is 0.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Jul 2011 20:00, "Mark Struberg" wrote:
> yea, th
yea, that is good news. Will try to tweak this for all wagon tests too.
Do you know since when this works? Is this available in jetty-6.1.26?
Btw, when going through our Tests I found lots of tests which do not cleanup
the target/local-repo (or similar) before they run. Some of them only work
b
the buildhelper goal is for when you are launching jetty/etc from the pom.
or when you need to filter the port into on disk resources.
if launching within the test case, just assign it to port 0. a request for
port 0 is a request for an unused port in the top 16k (or depending on the
os, anywhere
the build helper has a goal for this.
On Jul 31, 2011, at 12:09 PM, Mark Struberg wrote:
> Hi Olivier!
>
> Do you have a sample how to incorporate this into our unit tests? I only knew
> that jetty is able to assign a random port for the stop port, but didn't know
> that the same exists for th
ah, I knew you did something like this but could not find it :)
question: ok, random port, but random and guaranteed to success? ie it makes
the effort to find an unused port?
see r1152587: I chose an arbitrary port
we should add this to a FAQ, since this is a common use case
Regards,
Hervé
L
Hi Olivier!
Do you have a sample how to incorporate this into our unit tests? I only knew
that jetty is able to assign a random port for the stop port, but didn't know
that the same exists for the serving port.
LieGrue,
strub
--- On Sun, 7/31/11, Olivier Lamy wrote:
> From: Olivier Lamy
>
Hello
Jetty is normally able to start on a random port.
I have fixed that recently in archetype.
Imho better solution.
Which tests fail for this reason ?
--
Olivier
send from a mobile
Le 31 juil. 2011 17:43, "Mark Struberg" a écrit :
> Hi!
>
> While browsing our CI results I saw randomly failing
Hi!
While browsing our CI results I saw randomly failing tests. Most of them are
caused by starting jetty on a specific port which already is in use by another
test.
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
Clearly if 2 unit tests fire up a j
If you check a settings.xml into the tree where this job can fetch it,
I will try to go from there.
On Sun, Jul 31, 2011 at 10:58 AM, Mark Struberg wrote:
> Hi Benson!
>
> Thanks for this information!
>
> I don't have much clue about jenkins (apart from reading the build messages),
> nor any det
not yet perfect, but much better than the previous version ;)
+1
LieGrue,
strub
--- On Sun, 7/31/11, Hervé BOUTEMY wrote:
> From: Hervé BOUTEMY
> Subject: Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting
> Exec version 1.0.1
> To: "Maven Developers List"
> Date: Sunday,
+1
tested on Maven Core with success
Regards,
Hervé
Le samedi 30 juillet 2011, Dennis Lundberg a écrit :
> Hi,
>
> We solved 46+1 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=
> Html&version=16829
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projec
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from reading the build messages),
nor any detailed info about the setup at the ASF.
Did you understand Dennis' problem description and do have mojo + knowledge how
to fix this on our CI? Our problem is most pro
Mark,
THe problem is this: jenkins gets going using information from the
global settings.xml before any command-line args are processed. So
you've created a monster, as it were. Luckily, there's a job option to
use an alternative settings so long as it's in the svn real estate
that the job knows a
That's fine, but I fear only as long as you don't use -Dmaven.repo.local on
your commandline. And exactly that's how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann wrote:
> From: Ansgar Konermann
> Subject: Re: non-reproducible issues on CI
> To: "Maven Devel
On 2011-07-31 14:42, Ansgar Konermann wrote:
> Had a similar if not same issue while developing a plugin. Fixed it by
> adding
>
>
> ${repository.integrationtests}
>
>
> to surefire plugin configuration in IT phase.
>
> Works for me with surefire-plugin 2.9 and invoker-plugin 1.5
>
> Regard
Had a similar if not same issue while developing a plugin. Fixed it by
adding
${repository.integrationtests}
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin 1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb "Dennis Lundberg" :
I've been meaning to check out the clirr-plugin - I'll add that to my TODO
reading list for the morning.
On 1/08/2011, at 12:15 AM, Mark Struberg wrote:
> PS: you can at least check the backward compat of your own lib with the
> maven-clirr-plugin.
On 31 Jul 2011, at 13:15, Mark Struberg wrote:
> I thought about that too, and actually don't think that there is a general
> solution.
>
> Two examples:
>
> * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new
> getParentLogger() method. To compile your own DataSource with jav
Potentially not. I suppose if there was a way to say [2.0.0,3.0.0) *excluding
SNAPSHOTS* then that would certainly be in my favor.
From memory there was a discussion some time ago regarding range resolution
excluding -SNAPSHOTs unless the artifacts were also in the current reactor
build, from
I thought about that too, and actually don't think that there is a general
solution.
Two examples:
* JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new
getParentLogger() method. To compile your own DataSource with java7 you need to
implement this method. It is perfectly compati
What if you could find another way to check API compatibility, would you need
this at all?
On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote:
> The use case that we originally came with in our discussions revolved around
> version ranges, and the fact that a version reference of "2.5.4" doesn't
On Jul 31, 2011, at 3:27 AM, Stephen Connolly wrote:
> i see two concerns that need separation.
>
> 1. the code that fetches dependencies from wherever they live.
>
Sure, I've known people to change this in many ways. Integration of legacy
artifact stores, migration strategies which involve p
ok, in the past i have had discussions with Jason over version range syntax.
Jason previously expoused the view that osgi format version numbers is the
-only- way to have version numbers, and anything else he would not support.
at the time i was working for a company where we had 5 segment version
Hi
Mark and I spent yesterday trying to figure out what is going on with
this failing build. Here are our finding this far for
maven-repository-plugin.
1. maven-invoker-plugin is used to install the current artifact
(maven-repository-plugin) into a special repository used by the ITs,
namely targ
Not from any of my use cases no.
Mark
On 31/07/2011, at 10:18 PM, Hervé BOUTEMY wrote:
> This lets the question of pluggable version comparison need: is there a real
> world example of unwanted version order?
Le dimanche 31 juillet 2011, Mark Derricutt a écrit :
> The use case that we originally came with in our discussions revolved
> around version ranges,
ok, that's not a version comparison but version (range) resolution question:
version ordering is here to define how artifacts are ordered, then the
The use case that we originally came with in our discussions revolved around
version ranges, and the fact that a version reference of "2.5.4" doesn't
actually mean " give me 2.5.4" but rather "I would like 2.5.4, but meh, use
something higher if you need to".
In the case were you have artifacts
I see this one regularly and don't frankly understand the need other than pure
theory.
Actual version comparison supports every numbering scheme I ever saw in
reality. The only choice that has been made that is a pure choice (neither
good nor bad, just a choice had to be made) is that unknown qu
IMHO, it can make sense as a CLI option, to let you try multiple strategies
(normal, GUMP-like ie. LATEST, compatibility ie. OLDEST)
But I doubt it has a meaning neither at project level nor user level, nor
install level.
Project level is IMHO impossible, like Igor seems to have tried :)
User lev
Fundamental issue here is having multiple ways to construct dependency
dirty DAG and prune the DAG to eliminate conflicts. Resolution starts
with artifact A using one strategy and then hits dependency artifact B
that uses another strategy. Forcing the same strategy on A and B will
almost certainly
Hi Igor!
I'm also not sure if it makes sense/works out to apply a different
DependencyResolver on per project base. This is also kind of a chicken-egg
problem.
But I could imaging that this could be done in settings.xml!
LieGrue,
strub
--- On Sun, 7/31/11, Igor Fedorenko wrote:
> From: Igor
agree.
The OSGi naming schema makes it easier to detect if a version is higher or
lower than another. But the trade off is numerous, let alone compatibility with
the versions of already existing maven artifacts.
LieGrue,
strub
Just as a side note: The handling of multiple jars in different ve
It is sort-of possible to plug per-project dependency resolver and this
is more or less how Tycho works already (I can provide more details
about implementation, if you are interested). The problem is on the
consumer end. What dependency resolution logic you expect to apply if
standard maven proje
oh i forgot to mention. i also think that version comparison rules should be
plugable.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Jul 2011 08:27, "Stephen Connolly"
i see two concerns that need separation.
1. the code that fetches dependencies from wherever they live.
2. the code that computed the dependencies graph.
#1 should be something that is plugable, and in essence could be part of the
repositories definitions... in saying that, i think we need a way
48 matches
Mail list logo
