To my mind what you want to do is write an enforcer custom rule that
checks all the compile and runtime scoped dependencies against a
whitelist server...
I'd have a webserver that can e.g. take a query of the form
http://someurl/.../check?groupId=artifactId=_version=_classifier=
that would possibly work if there is a way for the enforcer to retrieve
scope information from the artifact - is this possible?
Is it also possible for transitive dependencies, i.e., will the enforcer let
me allow the same artifact to go through when using it as a transitive dep
of a test-scope
I would think that you should be able to do that from an enforcer rule...
Of course I have not tried...
But if you need those kind of changes in enforcer, that would be a lot
quicker to get than changes to Maven's core...
Plus, such a custom rule would be of use to not just commercial
projects,
ok, will give it a go - any pointers on the API I should be looking at in
order to determine an artifact's scope? I'm not scared of trawling through
maven's source code myself, but a helpful pointer in the general direction
would be appreciated.
Thanks,
Ishaaq
2008/7/1 Stephen Connolly [EMAIL
:
http://www.nabble.com/fatal-dependency-management-flaw-in-maven--tp18188983p18211522.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
PROTECTED]
--
View this message in context:
http://www.nabble.com/fatal-dependency-management-flaw-in-maven--tp18188983p18211522.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/fatal-dependency-management-flaw-in-maven--tp18188983p18211522.html
Sent from the Maven - Users mailing list archive
As far as I know, the answer is 4.
Generally I expect your problem(s) can be solved by setting up
multiple environments, each with its own repo manager and liberal use
of rm -rf ~/.m2/repository (or dependency:purge-local-repository).
Then you would specify which repo to connect to with a profile
Well, not knowing who else uses maven out there I have no reasonable way to
verify or deny your claim that this is not useful for 95%. I can only say
that I find it hard to believe that only 5% of maven users would conform to
both of the following criteria - but then again, I don't really know:
Hi Ishaaq,
Ishaaq Chandy wrote:
Well, not knowing who else uses maven out there I have no
reasonable way to
verify or deny your claim that this is not useful for 95%. I
can only say
that I find it hard to believe that only 5% of maven users
would conform to
both of the following criteria
Hi Jörg,
Thanks for your reply.
Unapproved transitive deps can creep in because we do not lock down plugin
dep versions - for e.g. even maven's compiler plugin could conceivably have
transitive deps - we do not explicitly lock down the version numbers of each
and every plugin we use - yes, this
2008/6/30 Ishaaq Chandy [EMAIL PROTECTED]:
Hi Jörg,
Thanks for your reply.
Unapproved transitive deps can creep in because we do not lock down
plugin
dep versions - for e.g. even maven's compiler plugin could conceivably have
transitive deps - we do not explicitly lock down the version
Hmm, so in short you're telling me that I should completely lock down my
build process simply because maven can't differentiate between plugin deps,
test deps and compile/runtime deps.
Look, I know I'm starting to sound like a whining complainer and I wouldn't
blame you if you got annoyed, but
Ishaaq Chandy wrote:
Hmm, so in short you're telling me that I should completely
lock down my
build process simply because maven can't differentiate
between plugin deps,
test deps and compile/runtime deps.
Look, I know I'm starting to sound like a whining complainer
and I wouldn't
blame
2008/6/30 Ishaaq Chandy [EMAIL PROTECTED]:
Hmm, so in short you're telling me that I should completely lock down my
build process simply because maven can't differentiate between plugin deps,
test deps and compile/runtime deps.
my perspective (as a maven user) is that if I was concerned
Aha! I think I see now why you think I have a special case, I think its a
simple case of misunderstanding - for which I'll assume all fault is mine :)
Locked down versioning is not really the point. Even if we had a locked
versions of the test (in fact we do lock the test dependency versions) and
2008/7/1 Stuart McCulloch [EMAIL PROTECTED]:
my perspective (as a maven user) is that if I was concerned
about dragging in artifacts with certain licenses then I'd want
to be 100% sure I had everything locked down build-wise.
that seems easier to defend (legally-speaking) than relying
on
2008/6/30 Ishaaq Chandy [EMAIL PROTECTED]:
Well, assuming that a hypothetical implementation of maven only downloads
compile/runtime deps from the repo that we actively control and restrict
access to, wouldn't that be safe enough? I can't think of a scenario where
this would lead to accidents
On Mon, Jun 30, 2008 at 4:14 AM, Ishaaq Chandy [EMAIL PROTECTED] wrote:
Well, not knowing who else uses maven out there I have no reasonable way to
verify or deny your claim that this is not useful for 95%. I can only say
that I find it hard to believe that only 5% of maven users would conform
Yup, you're assuming that maven works as it currently does - i.e. it is
unable to remember the context of how the dependency was originally pulled
down.
However, even if you did assume that, it would be easy to work around if you
enforced a full build from scratch to delete the local repo. As a
There would be other ways to accomplish this -- for instance, if Maven were
aware of the license (if it were published in the POM), you could put
It is published in the pom.
You'd probably still have to cope with libraries that are (say) GPL,
but don't declare themselves in the pom as such.
I agree to a certain extend - i.e. maven is not really the tool to use for
license verification, but since dependency management and license management
are related issues I'd like to leverage its dependency management ability to
solve my license verification needs, but it looks like it stops me
However, even if you did assume that, it would be easy to work around if you
enforced a full build from scratch to delete the local repo. As a developer
you may decide to avoid doing a full build but our continuous integration
environment would certainly enforce it and would catch the problem
There would be other ways to accomplish this -- for instance, if Maven were
aware of the license (if it were published in the POM), you could put
You'd probably still have to cope with libraries that are (say) GPL,
but don't declare themselves in the pom as such.
Which is why people who
... and lo - I can't even read -
http://maven.apache.org/plugins/maven-enforcer-plugin/rules/bannedDependencies.html
On Mon, Jun 30, 2008 at 4:48 PM, Nigel Magnay [EMAIL PROTECTED] wrote:
However, even if you did assume that, it would be easy to work around if you
enforced a full build from
Or libraries that illegally (whether maliciously or not) have
not-redistributable transitive dependencies of their own that are not
compatible with their own licenses.
So, yes, I agree, you can't really legally rely on that - you'd have to
manually check each dep down the whole dependency tree -
The dependency report in the soon-to-be-released next version, 2.1, of MPIR
plugin lists the license used (assuming the license section is filled in in
the particular pom). That should help verifying the licenses used and
needed.
Kalle
On Mon, Jun 30, 2008 at 8:53 AM, Ishaaq Chandy [EMAIL
2008/7/1 Nigel Magnay [EMAIL PROTECTED]:
However, even if you did assume that, it would be easy to work around if
you
enforced a full build from scratch to delete the local repo. As a
developer
you may decide to avoid doing a full build but our continuous integration
environment would
On Mon, Jun 30, 2008 at 5:10 PM, Ishaaq Chandy [EMAIL PROTECTED] wrote:
2008/7/1 Nigel Magnay [EMAIL PROTECTED]:
However, even if you did assume that, it would be easy to work around if
you
enforced a full build from scratch to delete the local repo. As a
developer
you may decide to
Hi Ishaaq,
Ishaaq Chandy wrote:
Aha! I think I see now why you think I have a special case, I think its a
simple case of misunderstanding - for which I'll assume all fault is mine
:)
Locked down versioning is not really the point. Even if we had a locked
versions of the test (in fact we
1. A locked down repo in which only approved versions of some deps
exist.
2. An open repo which proxied on to maven central.
This is commonly done where the CI system uses only the approved
versions and the devs are free to use the proxied one. It simply means
that they must be sure that the
Hmm, so in short you're telling me that I should completely lock down
my
build process simply because maven can't differentiate between plugin
deps,
test deps and compile/runtime deps.
No, only because it will save you hassle later.
Another thing to consider is that regardless of what decisions
(slightly) surprised there isn't a dependency black/whitelisting
enforcer rule - but just because I haven't seen one doesn't mean there
isn't one out there.
There is. It currently doesn't consider effective scope, but it could.
It seems to me to be a management problem rather than a technical problem
although the technical tools could help the manager identify the problem.
If you inform your developers that they can only use certain libraries and
have to check with your (or someone) if they want to use other libraries,
On Mon, Jun 30, 2008 at 9:10 AM, Ishaaq Chandy [EMAIL PROTECTED] wrote:
On the contrary, I actually do want to codify this with my pom - i.e. I want
to be able to instruct maven via my pom on how to decide which of the
configured repos to use when downloading certain types of dependencies.
I agree it is a management problem - the bulk of th work would have been
done in the management of the internal closed repo - I just sort of expected
to find some way to get maven to stop polluting the artifacts and their
transitive deps retrieved from this repo from the other more open repos used
2008/7/1 Brian E. Fox [EMAIL PROTECTED]:
There are some proposals on the table to further break down the local
repo and until those are implemented, this use case can't really be
fully handled...regardless of the implementation of scope based repos.
--Brian
A pity, but at least someone is
Well, that could possibly work except that there is no way I can get that
internal locked down build to actually run - remember that maven does
everything via plugins - even the compilation is done using a plugin - so
all the plugins would have to be added to the closed repo - thus polluting
it
I recently asked this list about segregating project dependencies based on
scope type, i.e. for e.g., ensuring that maven only downloads test
dependencies from one repository and other normal dependencies from another
repository. I did not get an answer - which can only mean 1 of 3 things:
1. It
39 matches
Mail list logo
