(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 artifacts MUST come from 'central'. There are other open source
repo's in wide use. Same with private/corporate repos.
Forcing an edit to settings.xml (usually located in the user home dir)
is also a maintenance issue for automated builds.
What about some sort of local "override" of settings.xml?
eg: If the directory containing the pom.xml ALSO contains a file named
settings.xml (or local.setting.xml, or .settings.xml, not sure what name
is best), then the "project local" settings will take precedence.
This way, the simple "get latest from the bank and build" use case is
still maintainable.
I recognize the security issues previously mentioned, but every time I
have to touch a file outside the project directory in order to ensure
anyone can build a project, I feel it is a step backwards...
Dan Rollo
Arnaud HERITIER wrote:
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...@gmail.com> wrote:
2009/10/28 Stephen Connolly <stephen.alan.conno...@gmail.com>
2009/10/28 Arnaud HERITIER <aherit...@gmail.com>
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 fun but at least they
have
to understand what they are doing and they don't rely on some Maven
magic.
Also there is nothing stopping us from writting a plugin that imports the
repositories into your settings.xml
In which case for an out of the box build, you would do something like
svn co
mvn bootstrap:settings
Note that this would print out big ugly warning messages and prompt for
each
repository... but at least people don't have to figure out how to edit
their
settings.xml ;-)
mvn install
For corporate environment they are already doing it to define the global
proxy and it is now easier with plugins like the one in nexus.
If we continue to define repositories in POM not to resolve artifacts
but
just to document the build with a nice warning from maven with repo
lists
when an artifact isn't found, I think we could have a good compromise.
Arnaud
On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdca...@commonjava.org>
wrote:
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
support that repository as public infrastructure...along with
providing
ticket/bug tracking for that repository's reachability along with the
build
files or the source code for the app itself.
Of course, there's not much reason I can think of that an OSS project
wouldn't just configure synchronization with central if they're going
to
go
to all this trouble...but for non-OSS I can see them using the above.
In
that case, there's a chance they would want to authenticate/control
access
to that repository anyway, in which case the user would need to modify
his
settings.xml anyway...
-john
Jesse McConnell wrote:
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 a wiki page or a webpage detailing that is
not acceptable imo as it makes it difficult for the user as they need
to _find_ that page.
Now I would be pro notification as well, along the lines that brett
was mentioning I think
I can declare a repo in a third party integration, perhaps against a
corporate repo that has some open source component they are not
syncing to central....and that is _ignored_ in the build, ie never
consulted, but when that is detected and if the build is not able to
complete it should pump out that information to the user declaring
that other repositories have been detected and that perhaps missing
dependencies are located in there...
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Oct 28, 2009 at 09:17, Paul Gier <pg...@redhat.com> wrote:
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.
The people who have a corporate policy to only download from central
are
already breaking their policy whether they list the alternate repo
in
settings.xml or it is added from a dependency.
With that said, I'm ok with having it configurable as Jesse suggests
as
long
as the default behaviour is to not add the repositories to the
build.
Jesse McConnell wrote:
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.
since we can't rightly force people to install and maintain
repository
managers, at first blush I would probably error on the side of a
option in the settings.xml a la offline
<transitiveRepositories>true/false</transtiveRepositories>
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Oct 28, 2009 at 07:03, Brett Porter <br...@apache.org>
wrote:
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 things now).
As to what the user is guided to do - I assume that is to declare
them
as
repositories in the current project, or to refer to their
repository
manager's documentation to add it there (with this being
recommended).
In
the long run I'd hope Maven can better handle multiple
repositories
OOTB
(in
a way that still complements the use of a repository manager) -
actually
I
remember briefly talking to Brian about that at last year's
ApacheCon
Maven
BOF :) Time flies...
- Brett
On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
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 repository R hosting B.
Now, when it comes to resolve B's POM/JAR (and its transitive
dependencies) in the context of building the project, should
Maven
3
also
consider R (like currently done in Maven 2) or only those
repositories
that
are available for the root of the dependency graph, i.e. the
repositories
declared in the POM of the project and the settings?
Besides the question of the degree of backward-compat we want to
keep,
the
issue with ignoring the repositories declared in dependency POMs
I
see
is
the effect on open source projects and their consumers. If one
project
consumes the artifacts of another, do we want the first project
to
redeclare
all repositories required to resolve the transitive dependencies
of
the
second project? Some arguments for the other side can be found in
[1].
So, where do we want to go with this?
Benjamin
[0]
http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
[1] http://jira.codehaus.org/browse/MNG-3056
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
