On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies wrote:
> But why do 2.0.10 users need to build against brand-spanking-new poms?
> And, if they do, could we give them a downconversion tool?
>
the new poms will arrive to central for everyone to use..
Milos
>
> On Tue, Jun 28, 2011 at 6:47 PM, S
On 28 June 2011 15:40, Benson Margulies wrote:
> Sebb,
>
> I think that you are pointing at the dilemma at the center of this.
>
> Anything like this that we put into the top pom is inherited unless
> overriden, and people are skittish about accidently making everything
> part of the Maven project
But why do 2.0.10 users need to build against brand-spanking-new poms?
And, if they do, could we give them a downconversion tool?
On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly
wrote:
> maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
> tricky... even our own model
maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
tricky... even our own model parsing is not forgiving if i recall
correctly... so far as 3.0.x too
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a dire
On Tue, Jun 28, 2011 at 6:23 PM, Olivier Lamy wrote:
> FYI I have created some jobs for core integration testing :
> * ubuntu (1.5 and 1.6)
> * windows (I have to investigate why it failed currently)
> * osx (not yet osx here to debug :-) : I wonder if there any symlink
> on osx for /tmp ?)
/tmp
This is a new thread for the topic I accidentally started with Steven.
I'm fairly new around here, so please try to forgive me for
(re)stating the obvious.
There is an ecosystem of tools that parse poms. They don't use any
library we give them, they just parse them.
We want old tools to handle n
FYI I have created some jobs for core integration testing :
* ubuntu (1.5 and 1.6)
* windows (I have to investigate why it failed currently)
* osx (not yet osx here to debug :-) : I wonder if there any symlink
on osx for /tmp ?)
See jobs here https://builds.apache.org/view/M-R/view/Maven/ with
nam
+1
Regards,
Hervé
notice: the staging site is http://maven.apache.org/staging/maven-release/
Le lundi 27 juin 2011, Stephen Connolly a écrit :
> Hi,
>
> We solved 12 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144&styleName=
> Html&version=16778
>
> Staging repo:
>
+1
Thanks !
--
Olivier
2011/6/27 Stephen Connolly :
> Hi,
>
> We solved 12 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144&styleName=Html&version=16778
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-061/
>
> Source distribution:
> https://r
done [1]
site deployed [2]
any comments appreciated to continue to improve the documentation
Regards,
Hervé
[1] http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup
[2] http://maven.apache.org/pom/asf/
Le mardi 28 juin 2011, sebb a écrit :
> May I make a plea for the ASF POM
On 28 June 2011 16:27, Benson Margulies wrote:
>>
>> I agree, but if you stick to the "cannot change the pom format" the
>> only thing you can just about do is introduce a new scope.
>>
>
> Is this, "let's make this feature before we're willing to change the
> pom" or "let's never change the pom".
I would offer
alsoProvides
for the feature you propose.
On Tue, Jun 28, 2011 at 11:11 AM, Stephen Connolly
wrote:
> On 28 June 2011 14:38, Benson Margulies wrote:
>>>
>>> Because why should I have to always state that I'm using
>>> org.slf4j:log4j-over-slf4j and that it provides log4j:log4j
>
> I agree, but if you stick to the "cannot change the pom format" the
> only thing you can just about do is introduce a new scope.
>
Is this, "let's make this feature before we're willing to change the
pom" or "let's never change the pom".
---
On 28 June 2011 14:38, Benson Margulies wrote:
>>
>> Because why should I have to always state that I'm using
>> org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much
>> better that the pom for org.slf4j:log4j-over-slf4j says "oh and by the
>> way I provide log4j:log4j myself so you don
Sebb,
I think that you are pointing at the dilemma at the center of this.
Anything like this that we put into the top pom is inherited unless
overriden, and people are skittish about accidently making everything
part of the Maven project.
Where would you propose that we put a link to that it wou
>
> Because why should I have to always state that I'm using
> org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much
> better that the pom for org.slf4j:log4j-over-slf4j says "oh and by the
> way I provide log4j:log4j myself so you don't need to pull it in
> transitively if you depend on
On 28 June 2011 14:01, Benson Margulies wrote:
>> The critical scope to add for me is something along the lines of
>> "provides" or "supplies" or "embeds-equivalent"
>>
>
> Why is this a scope and not just more configuration inside the
> element?
>
>
>
>
>
>
>
I finally find a solution. In the web-app/web-inf/lib directory, there was a
jar file who was sharing the same name with the dependent jar file.
For a reason i don't understand, maven-war-plugin used to take this old jar
file rather than the freshly one i installed in my local repository.
---
> The critical scope to add for me is something along the lines of
> "provides" or "supplies" or "embeds-equivalent"
>
Why is this a scope and not just more configuration inside the
element?
> So that when computing the dependency tree, we
Hi all,
Sorry for annonying you, but i have searched my problem in the wiki, in
the documentation,
on the web, post it in various forums, in user-list and no one seems to be
able to answer me.
Here it is :
I have a web-app configured with a pom.xml.
This web-app relies on another maven m
On 28 June 2011 11:38, Stephen Connolly wrote:
> On 28 June 2011 11:31, Benson Margulies wrote:
>> I was pretty sleepy last night.
>>
>> My residual disagreement is that 'provided' doesn't just mean 'copy to
>> local repo'. It means 'copy to local repo and put in test classpath.'
>> Yes, I now ge
On 28 June 2011 11:31, Benson Margulies wrote:
> I was pretty sleepy last night.
>
> My residual disagreement is that 'provided' doesn't just mean 'copy to
> local repo'. It means 'copy to local repo and put in test classpath.'
> Yes, I now get it, an appropriate packaging avoids any classpath. Th
I was pretty sleepy last night.
My residual disagreement is that 'provided' doesn't just mean 'copy to
local repo'. It means 'copy to local repo and put in test classpath.'
Yes, I now get it, an appropriate packaging avoids any classpath. The
word 'provided' is used because it's 'provided' by the
I get the same failure on my Mac. I recommend to configure a jenkins job
as multi-configuration type, see eg
https://builds.apache.org/job/doxia/
(Just choose multi-configuration-project instead of maven2/3 project
when adding the job)
HTH,
-Lukas
Benson Margulies wrote:
I just added an
On Mon, 27 Jun 2011 10:23:27 +0100
Stephen Connolly wrote:
+1 (non-binding)
Thanks,
Tony
> Hi,
>
> We solved 12 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144&styleName=Html&version=16778
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven
+1
LieGrue,
strub
--- On Mon, 6/27/11, Stephen Connolly wrote:
> From: Stephen Connolly
> Subject: [VOTE] ReleaseMaven Release plugin version 2.2
> To: "Maven Developers List"
> Date: Monday, June 27, 2011, 9:23 AM
> Hi,
>
> We solved 12 issues:
> http://jira.codehaus.org/secure/ReleaseNote.
Apologies: I hit the wrong button.
I am enjoying this thread. My main observation so far is that if you need one
custom scope (and I think you do) then you will need more. "Provided" is not
enough.
The custom scope seems to let you get at lists of dependencies that have a
special purpose. Th
27 matches
Mail list logo
