Jason, behaviour != implementation !
If someone likes to store his artifacts in a database or taking it from a p4,
why not?
And actually having a much cleaner interface on our side would be highly
welcome!
LieGrue,
strub
--- On Sat, 7/30/11, Jason van Zyl ja...@sonatype.com wrote:
From:
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
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
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
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
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 i...@ifedorenko.com
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
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
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
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
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
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?
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
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
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
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
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
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
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 java7 you
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.
Had a similar if not same issue while developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin 1.5
Regards,
On 2011-07-31 14:42, Ansgar Konermann wrote:
Had a similar if not same issue while developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with
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 ansgar.konerm...@googlemail.com wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
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
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
+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=11146styleName=
Htmlversion=16829
not yet perfect, but much better than the previous version ;)
+1
LieGrue,
strub
--- On Sun, 7/31/11, Hervé BOUTEMY herve.bout...@free.fr wrote:
From: Hervé BOUTEMY herve.bout...@free.fr
Subject: Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting
Exec version 1.0.1
To:
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 strub...@yahoo.de wrote:
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from reading the build messages),
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
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 strub...@yahoo.de a écrit :
Hi!
While browsing our CI results I saw
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 ol...@apache.org wrote:
From:
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é
the build helper has a goal for this.
On Jul 31, 2011, at 12:09 PM, Mark Struberg strub...@yahoo.de 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
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
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
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 strub...@yahoo.de
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
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 ja...@sonatype.com wrote:
From: Jason van Zyl ja...@sonatype.com
Subject: Re: non-reproducible
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
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
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
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.
2011/7/31 Dennis Lundberg denn...@apache.org:
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
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 just
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
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
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 is working
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
+1
-Lukas
Dennis Lundberg wrote:
Hi,
We solved 46+1 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501
There are still a couple of issues left in
49 matches
Mail list logo
