Yeah exactly, I think we are roughly on the same lines, if the war just proxies stuff off to a filemanager server or whatever, why have the full filemanager jar? Just have some interface layer that allows the war to communicate with the remote filemanager server and suddenly you'll have a 2mb war.
On Fri, Oct 30, 2015 at 12:27 PM, Lewis John Mcgibbney < lewis.mcgibb...@gmail.com> wrote: > Ok so the issue I suppose I am eventually getting at here is that we have a > 3 ~65MB .war artifacts within the codebase. > That seems a bit mental to me. > We must be able to make a skinny war without dependencies and just make > that available. The 65MB .wars need to be reduced in size. > > On Friday, October 30, 2015, Tom Barber <tom.bar...@meteorite.bi> wrote: > > > 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 <javascript:;>> 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 > > <javascript:;>> 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:;> > > > > <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:;> <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:;> > > > > <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:;> <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:;> <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:;> <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:;> <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* > > > > > > > > -- > *Lewis* >
