On Thu, Mar 5, 2009 at 10:26 AM, stanlick <stanl...@gmail.com> wrote: > > Thanks Wes -- > > First off, you are preaching to the choir bro. My question stems from the > fact we have a small army of lawyers who stake their careers on looking in > these rabbit holes and they are now asking me to help them dig! Telling > them not to concern themselves with this and that archive for whatever > reason, only makes them want to dig deeper. Again, lawyers! Funny thing is > when you are at the top of the mountain with piles of assets, you become a > target. Do you think if the woman had spilled her hot coffee at Joe's Java > Drive-thru that she would have been awarded $1,000,000? > > I'm not interested in what version of Rose you used unless you include Rose > in the distribution. If you dump the struts-2.1.6 archive out on the table, > you will find it contains fifty-seven archives of its own. You and I > realize why testng-5.1.jar is there and that it might not even be touched > in-house -- but that does not mean that it will not once struts-2.1.6 is > accepted. So here is what I would like to do.
I guess I wasn't considering how you retrieve Struts. If you are pulling down struts2-all-blahblah.zip, then you will get everything. I was assuming a build starting from a maven archetype and working up from there. This might be one way to compromise. Instead of grabbing struts-all, just learn to start from an archetype and add individual dependencies as they are needed. Maven will only retrieve what you tell it to. As a side note, I too worked at a top-of-the-heap company for a long while, but our legal team was very well educated about licensing issues. I think the difference was that we were a *nix shop from the get-go, so most of us were familiar with the technology and culture. In fact, one of the projects I worked on (http://www.atomicmpc.com.au/News/13219,aol-moves-to-linux-and-mozilla.aspx), I worked close with legal to make sure that we were in license compliance and it went pretty smooth. Had we been sued, I felt confident that our attorneys understood FOSS to the extent that they could rigorously defend it. > > 1) Build a comprehensive list of the jars included in say, struts-2.1.6 and > those dependent downstream jars > > 2) Feed this list of archives to FOSSology where it is prepared to sniff out > the stack of respective licenses > > 3) Hand the comprehensive stack of licenses to the legal team > > 4) Repeat for next requested FOSS offering > > Is Maven a candidate for this task? We have our own build system and do not > use Maven, however, I think we could use it for this legal request. I have > experimented with its dependency:tree, but it seems to build only a partial > tree. Suppose *I did* want to do a maven build that touched all fifty-seven > files for the express purpose of building this comprehensive dependency > tree. Is there such a POM? Would creating such a POM produce the > comprehensive tree? > I think Maven might be a candidate for your task, but maven is a hard thing to adopt for just one task... Maven is sort of an all-or-nothing kind of deal. In your custom build environment, have you considered trying to jimmy Maven into the mix? I had to do force apache ant into a custom CI farm (created to automate unix builds with make, make + java = not fun), it's not fun, but it has benefits. As far as an all-inclusive pom, there are a few considerations. There is not likely to be a project that includes *everything* that can be used with struts2. For instance, I don't think you can have both the Guice plugin and the Spring plugin in a single project... We only run a single objectfactory, so plugins like this would clash. (There are others like plexus that fall under this category). If you can, I would suggest trying to get maven into the mix as much as possible. To me, it seems the easiest method would be to create a maven plugin that tracks which packages have been used within your company. If the license is not known for a package, then you can specify the license, then whenever another project uses that package (directly or as a transitive dependency), it can be considered blessed. Many poms include their license information (check the license section here- http://www.jarvana.com/jarvana/search?search_type=inspect_pom&path_to_pom=/com/opensymphony/xwork/2.1.2/xwork-2.1.2.pom), which would make it that much easier for you to build a tool around. You'll have the benefit of only needing to research what you actually use and automating the process nearly completely. Maven has the benefit that artifacts will be referred to by identifiers, so you don't have to worry about ambiguity with jar file names (i.e., how do you know we didn't rename a jar file before putting it in struts2-all-blah.zip? Not that we would, but there is ambiguity). -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
