> I still maintain, as I have said in other threads, you should audit
> not enforce lock down.
Why is that? It doesn't seem a particularly valid method in my current
environment, but I'm willing to listen.
From my understanding, Maven currently has no capabilities to lock
down these artifacts so if you want such a solution you need to go
through the burning hoops you are suggesting and even then I don't
think you will get to the solution you desire.
I often find the desire to "lock down and control" is a knee jerk
reaction to a trust/knowledge issue and that the amount of up front
effort required to put these controls in place far outweighs the
benefits especially when any problems are exceptions not the norm.
Your goal is to verify that your projects are using sanctioned artifacts.
The reasons for this are likely:
1) to provide a stable architecture which you can test against
2) ensure license conformance
Option 1) Somehow lock down maven to only use the sanctioned versions
Effort: Huge
Option 2) Automate the audit process to confirm that your projects use
sanctioned versions
Effort: Less than Huge.
So I would choose to automate the audit process because it is less effort.
The bonus being I have a report that shows the results of the audit,
with a lock down approach there may be some way to circumvent the lock
down.
The only environments I can't see this working for are high security
environments with trusted/untrusted networks. I don't have a solution
for that.
I think my developers are competent for the most part, given that they're a
fairly large group broken into several pieces. But essentially to a
(gender-nonspecific pronoun) they are not competent with maven, build
processes in general or the reasons behind the controls associated with
those processes.
I have the same problem but for the most part they don't need to know
this level of details.
They can get away with mvn eclipse:eclipse and the dependencies
correctly setup by a configuration controller or the solution
architect of the project and defined in parent poms.
But providing training is always a good thing because the developers
really should have an appreciation of this process.
I disagree about the lockdown vs. audit question, but I don't completely
disagree...except when I'm obligated to do otherwise by the terms of my
employment. Like at each commercial environment that I've worked in for
the last several years.
I think audits usually work to handle dependency issues, and recommended
them prior to release. But my current working dependency set is now over
1000 artifacts, and that's just a bit too much to ask. Plus, a couple of
times before I got here an artifact slipped through the audit cracks so
caching proxies are the only choice that I can see. I'm charged with
working on an "accepted asset" list that would scan checked in poms and
report checkins that had dependencies not on the list, but that's a few
steps down the to-do list.
An artifact slipping through the cracks is most likely the result of
oversight by someone.
It would take a super-human effort to manually audit 1000 artifacts
with zero defects.
IANAL, but I do try to keep up with the legalities associated with licensing
and if you're a largish firm that sells software and somebody catches on
that you've distributed something unacceptably then it's your buttocks in
the fire. That fire would also, very likely, include the firing of me. :)
There has been talk before about a license manager/scanner.
Since all of the artifacts on the repositories are open source the
only problem would be if the license was one of those that cause your
developed software to also become open source and this is the type of
thing that a licence report could provide.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
