Le Thu, 29 Oct 2009 02:09:47 +0100,
Olivier Lamy a écrit :
> Hi,
> If you provide a patch. "Pas de problèmes", I will review it and
> commit it. (or maybe dennis speak french too :-) ).
>
Fair enough :) It is done in http://jira.codehaus.org/browse/MCHANGES-183
> Merci,
> --
> Olivier
>
> 200
Hi,
If you provide a patch. "Pas de problèmes", I will review it and
commit it. (or maybe dennis speak french too :-) ).
Merci,
--
Olivier
2009/10/29 Tony Chemit :
> Le Wed, 28 Oct 2009 21:34:50 +0100,
> Dennis Lundberg a écrit :
>
>> Hi
>>
>> I plan on making 2 releases in the near future:
>>
>
Le Wed, 28 Oct 2009 21:34:50 +0100,
Dennis Lundberg a écrit :
> Hi
>
> I plan on making 2 releases in the near future:
>
> Maven Changes Plugin 2.2
> http://jira.codehaus.org/browse/MCHANGES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> Maven JAR Plugin 2.3
> http://jira.co
2009/10/28 Brett Porter
>
> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote:
>
> On Wed October 28 2009 10:53:10 am John Casey wrote:
>>
>>> I tend to agree, they should not really be used. It seems like these
>>> third-party repositories have a strong potential for causing network
>>> errors (in c
On 29/10/2009, at 2:08 AM, Daniel Kulp wrote:
On Wed October 28 2009 10:53:10 am John Casey wrote:
I tend to agree, they should not really be used. It seems like these
third-party repositories have a strong potential for causing network
errors (in cases where the repo is down or on a private n
Hi,
The vote has passed with the following result:
+1 (binding): Benjamin Bentmann, Vincent Siveton, Arnaud Héritier, John
Casey, Hervé Boutemy
+1 (non binding): Stephen Connolly
I will promote the artifacts to the central repository and continue with
the release.
Benjamin
Hi,
The vote has passed with the following result:
+1 (binding): Benjamin Bentmann, Vincent Siveton, Arnaud Héritier, John
Casey, Hervé Boutemy
+1 (non binding): Stephen Connolly
I will promote the artifacts to the central repository and continue with
the release.
Benjamin
-
Hi
I plan on making 2 releases in the near future:
Maven Changes Plugin 2.2
http://jira.codehaus.org/browse/MCHANGES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
Maven JAR Plugin 2.3
http://jira.codehaus.org/browse/MJAR?report=com.atlassian.jira.plugin.system.project:roadmap-pan
Hi all
I think it's about time we release Maven Site Plugin 2.1.
There are *a lot* of issued fixed in there, many of them thanks to the
upgrade to Doxia 1.1. To get a release out there are a couple of this to
consider:
1. What releases are needed?
maven-doxia-tools-1.1
doxia-1.1.2
doxia-siteto
On Wed, Oct 28, 2009 at 4:52 AM, Benjamin Bentmann
wrote:
> following a comment by Wendy on JIRA, I wanted to re-check what our plans
> are for repositories in dependency POMs. In more detail, how is dependency
> resolution in Maven 3.x expected to work
Thanks for bringing this up, Benjamin. I k
(Lurker post) ;)
To advocate the other side: I like the ability to define repositories in
the pom.xml because team members (oss or corporate) can simply "get
latest" from the source bank and things work OOTB.
I don't like the idea that the only way for things to work OOTB is if
all artifact
I agree we can have tooling for that.
We can imagine we add in user's settings a dedicated profile for the project
with all repositories (but for that we have to reactivate the repositories
chain to discover them ;-) )
On Wed, Oct 28, 2009 at 4:56 PM, Stephen Connolly <
stephen.alan.conno...@gmai
2009/10/28 Stephen Connolly
> 2009/10/28 Arnaud HERITIER
>
> I would like also that we don't use repositories defined in poms for all
>> reasons explained above.
>> It's right that changing this behavior will have an important impact
>> because
>> it could be difficult in certain cases to have a
2009/10/28 Arnaud HERITIER
> I would like also that we don't use repositories defined in poms for all
> reasons explained above.
> It's right that changing this behavior will have an important impact
> because
> it could be difficult in certain cases to have an OOTB Build (svn co + mvn
> install)
I would like also that we don't use repositories defined in poms for all
reasons explained above.
It's right that changing this behavior will have an important impact because
it could be difficult in certain cases to have an OOTB Build (svn co + mvn
install). Having to update user's settings isn't
Most debian packagers that don't have their apps in the default APT
sources provide a standard page somewhere on their website for adding a
new source. This would be pretty easy for third-party repository
providers to do, and would have the added benefit of making them really
think about it and
On Wed October 28 2009 10:53:10 am John Casey wrote:
> I tend to agree, they should not really be used. It seems like these
> third-party repositories have a strong potential for causing network
> errors (in cases where the repo is down or on a private network), and
> they definitely push the user
2009/10/28 John Casey
> I tend to agree, they should not really be used. It seems like these
> third-party repositories have a strong potential for causing network errors
> (in cases where the repo is down or on a private network), and they
> definitely push the user in the direction of trusting
The problem I see is that without being able to push up repositories
with third party artifacts that are not in central yet you still
depend on for integrations or things like that...you are out of luck
and need some mechanism of pushing that knowledge/information to the
user of the artifact...and
I tend to agree, they should not really be used. It seems like these
third-party repositories have a strong potential for causing network
errors (in cases where the repo is down or on a private network), and
they definitely push the user in the direction of trusting anything that
comes from any
I really think it should not be allowed, since it makes the builds less
predictable/reproduceable/secure. Most people I've talked to think it's a bug
when they first see it happening because they are trying to figure out why Maven
is downloading files from a random location on the Internet.
T
judging from the response I have gotten from people both wanting and
not wanting repositories declared for various integrations with jetty,
the problem folks seem to be ones where their corporate policy dictate
they can not use any repo other then central but they do not have a
repo manager setup.
Hello all,
I want to compile a Maven project from Java code. Thus, I am using the
MavenEmbedder (http://maven.apache.org/guides/mini/guide-embedding-m2.html).
Here is my code:
Configuration config = new DefaultConfiguration();
config.setUserSettingsFile(new File("..."));
config.setC
I would advocate not allowing them, but using them to provide useful
information in the case of a resolution exception that can easily
guide the user on what to do.
If folks strongly want to continue to allow it, I would go with a
prominent warning (which is the case for several other thing
Hi,
following a comment by Wendy on JIRA, I wanted to re-check what our
plans are for repositories in dependency POMs. In more detail, how is
dependency resolution in Maven 3.x expected to work here:
project ---depends-on---> A ---depends-on---> B
where the POM of A declares the repositor
25 matches
Mail list logo
