Right, so in here: https://github.com/apache/oodt/blob/master/webapp/components/pom.xml
You just have plain calls to the various OODT components that the webapps require to function. So, In the wmonitor I seen an exclusion on cas-filemgr which is the sort of thing I was expecting. I don't see how, for example, in the file manager you can scope a dependency, because surely when you build the core component for deployment in Radix or something you want the compile time dependencies in the filemgr lib directory, which means you can't scope it out AFAIK. In which case, you need to figure out which dependencies the webapps will never use, and exclude them. That said, your file manager webapp uses an API to communicate with the file manager server from what I understand. So if the filemanager was down opsui would still function, just not communicate with the FM. If that is the case, is there a requirement to bundle the file manager at all, or just create a light layer that allows for bidirectional communication with the file manager itself? Because its Wicket and JSP's there is a requirement there for OpsUI to use the jar, but you could swap it out for REST/JSON and have 0 dependency on the file manager if you are pushing all operations to it and not doing anything inside OpsUI.... If you can follow any of that rambling. Tom On Fri, Oct 30, 2015 at 11:39 AM, Lewis John Mcgibbney < lewis.mcgibb...@gmail.com> wrote: > What your saying about te Mars bars is true. > On the remainder... > 220 days is something that everyone on this list should take notice of. > This is serious reductions in what is commonly acknowledged throughout our > industry as technical debt. > @Tom, > Unpredictable builds in XMLRPC are OK... Because there are around 20 or so > people the see the builds when they happen. We can fix them reasonable > quickly or else realize that there is an environment error. > > On the other hand, what are we doing about these friggin war's? > > I did a bit of investigation. However I did not track it to parent Pom. I > don't think we have any scope set for many native dependencies e.g. OODT > deps inheriting from another OODT module. I think scope would help us > reduce the size of these beasts/ > > On Friday, October 30, 2015, Tom Barber <tom.bar...@meteorite.bi> wrote: > > > On a slightly different note, seen Sonar, I've used every trick in the > > book(Idea Analysis and fixing etc) and worked my nads off trying to get > the > > Tech Debt number down, and after whats probably 5 full days of work on > it, > > I've got rid of...... 220 days. Grim. > > > > Also because xmlrpc isn't mocked sometimes when the builds run on the > same > > box, you get the tests failing because of the port conflicts which > doesn't > > help. > > > > On Fri, Oct 30, 2015 at 10:19 AM, Tom Barber <tom.bar...@meteorite.bi > > <javascript:;>> > > wrote: > > > > > I was thinking more a Haggis followed by 2 battered mars bars... but > > > either way, not sure scope is particularly useful if you look at the > poms > > > they are dragged in as transient dependencies by the various OODT > > modules, > > > it might be more of a big fat, <exclude> block for the stuff that wont > > get > > > used by the webapps. > > > > > > > > > > > > On Fri, Oct 30, 2015 at 10:14 AM, Lewis John Mcgibbney < > > > lewis.mcgibb...@gmail.com <javascript:;>> wrote: > > > > > >> You bet they are heavy... > > >> Heavy as a sumo wrestler after eating five fish suppers and tanning > six > > >> bottles of fine french wine. Then washing it down with 2 mars bars > and a > > >> can of diet coca cola. > > >> <scope> is our friend. > > >> > > >> On Fri, Oct 30, 2015 at 1:51 AM, Tom Barber <tom.bar...@meteorite.bi > > <javascript:;>> > > >> wrote: > > >> > > >> > Looking at some of the dependencies in the fmbrowser for example, do > > you > > >> > need the full aws java sdk? (12mb), poi xml schemas(5.4mb), netcdf > is > > >> 11mb > > >> > although I assume that is required. > > >> > > > >> > Thats 28mb of dependencies without even trying, they are pretty > heavy > > >> > weight. > > >> > > > >> > Tom > > >> > > > >> > On Fri, Oct 30, 2015 at 5:20 AM, Mattmann, Chris A (3980) < > > >> > chris.a.mattm...@jpl.nasa.gov <javascript:;>> wrote: > > >> > > > >> > > Ack if we can reduce that would be stellar > > >> > > > > >> > > Sent from my iPhone > > >> > > > > >> > > > On Oct 29, 2015, at 10:12 PM, Lewis John Mcgibbney < > > >> > > lewis.mcgibb...@gmail.com <javascript:;>> wrote: > > >> > > > > > >> > > > No way... so it cas-product-0.11-20151028.223453-48.war > > >> > > > 60777 KB > > >> > > > I just cleared my ~/.m2 cache and by God these artifacts make > Moby > > >> > Dick's > > >> > > > forehead look like the tails side of a one pence piece.. > > >> > > > > > >> > > > > > >> > > > On Thu, Oct 29, 2015 at 5:57 PM, Lewis John Mcgibbney < > > >> > > > lewis.mcgibb...@gmail.com <javascript:;>> wrote: > > >> > > > > > >> > > >> OK so it turns out that > pcs-services-0.11-20151028.223756-49.war > > is > > >> > > around > > >> > > >> the same size > > >> > > >> 62186 KB > > >> > > >> These are HUGE for web application containers. > > >> > > >> > > >> > > >> On Thu, Oct 29, 2015 at 5:50 PM, Lewis John Mcgibbney < > > >> > > >> lewis.mcgibb...@gmail.com <javascript:;>> wrote: > > >> > > >> > > >> > > >>> Hi Folks, > > >> > > >>> I am slightly concerned that the pcs-opsui .war artifact is as > > >> large > > >> > as > > >> > > >>> Aundrey The Giants left arse cheek... 67831KB's to be precise. > > >> > > >>> I wonder if there is something we can do about this. None of > the > > >> OODT > > >> > > >>> dependencies have any <scope> so I wonder if there is actual > > >> scope to > > >> > > >>> reduce the soze of the artifact. > > >> > > >>> Lewis > > >> > > >>> > > >> > > >>> -- > > >> > > >>> *Lewis* > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> *Lewis* > > >> > > > > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > *Lewis* > > >> > > > > >> > > > >> > > >> > > >> > > >> -- > > >> *Lewis* > > >> > > > > > > > > > > > -- > *Lewis* >
