And you can just stick the "file" with the list of allowed dependencies in
the repo and pass it as a dependency to your plugin in the config. Nobody
can fool with it there so its better than putting it in the source
repository (e.g. SVN, CVS). And its easier than trying to put it on a whole
'nother
doh! I should have thought of that. :)
Thanks
2008/7/1 Minto van der Sluis <[EMAIL PROTECTED]>:
>
> Hi Ishaaq,
>
> I am not sure but it seems like the dependency plugin is a good candidate
> to
> look at. Looking at the output of dependency:tree it shows scope informatie
> as well.
>
> regards,
Hi Ishaaq,
I am not sure but it seems like the dependency plugin is a good candidate to
look at. Looking at the output of dependency:tree it shows scope informatie
as well.
regards,
Minto van der Sluis
Ishaaq Chandy wrote:
>
> ok, will give it a go - any pointers on the API I should be looki
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 PR
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,
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 ar
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=___
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 wit
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 so
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
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.
Thanks, you're the first person to admit that this is a valid use case and
not just some arcane process unique to my situation :)
2008/7/1 Brian E. Fox <[EMAIL PROTECTED]>:
> >1. A locked down repo in which only "approved" versions of some deps
> exist.
>
> >2. An open repo which proxied on to ma
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,
y
> (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.
>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 decisio
>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
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
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
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
> > environm
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 PROTE
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 - n
... 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 fro
> > 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
> 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 probl
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 fro
>
> 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.
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 de
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 con
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 acci
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 relyin
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/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
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
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 loo
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 v
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
Would it be possible to write an enforcer plugin rule that checks the
licenses of the dependencies?
regards,
Wim
2008/6/30 Jörg Schaible <[EMAIL PROTECTED]>:
> Hi Ishaaq,
>
> Ishaaq Chandy wrote:
> > Well, not knowing who else uses maven out there I have no
> > reasonable way to
> > verify or d
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 crit
oh - and I should also clarify, the use case is not as you said:
"specify which repos may/must contain specific artifacts"
that, I agree, would be overkill, but rather:
"specify which repos may/must contain dependencies of a certain scope type
(considering plugin as an additional scope-type for t
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:
1.
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 profil
41 matches
Mail list logo
