Searching for bundled jars: /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-configuration-1.1.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-collections-3.1.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/log4j-1.2.8.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-logging.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/hsqldb.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-logging-api.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-httpclient-3.0.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-lang-2.0.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/commons-codec-1.2.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/lib/jdic.jar /var/tmp/portage/net-proxy/paros-3.2.13-r1/work/paros/build/lib.jar It should also use our eclasses.
Someone should help me with that. I'm not much of a Java guy.
(In reply to comment #1) > Someone should help me with that. I'm not much of a Java guy. > Sure but there are a couple of packages that need to be packaged before we can get to work on this one. Basically paros is bundling a bunch of dependencies inside it and it should use the system installed copies.
Created attachment 130261 [details] paros-3.2.13-r1.ebuild My try on ripping out all the embedded jars from Paros's latest ebuild in portage (3.2.13). Dunno if submitting this only adds to the already overburdened java team's problems. :) - uses a modified build.xml (will attach below) - doesn't use paros's supplied startserver.sh either, but one generated by java-pkg_dolauncher - requires commons-configuration which is still only available in layman java-overlay (last I checked) - the ebuild features the use of firefox use flag as a way to configure the scan report log viewer, which currently has "mozilla" hardcoded in the Paros source
Created attachment 130263 [details] paros-3.2.13-r1-build.xml The modified build.xml for jar-stripped Paros. Changes are related mostly to the build paths (the old jars that were all dumped both into the lib/ and into the single giant paros.jar were no longer available) and in relation to that the runtime paths too. Added the Class-Path attribute to the resulting jar's manifest to let it find the deps during runtime.
(In reply to comment #3) > - requires commons-configuration which is still only available in layman > java-overlay (last I checked) Actually I moved commons-configuration from java-overlay to main tree a while ago.
(In reply to comment #5) > Actually I moved commons-configuration from java-overlay to main tree a while > ago. True. My bad, my repositories were up to date, but my brain must've been out of sync when typing that. :) Also, the changed build.xml could be turned into a patch against the Paros's regular supplied build.xml -- if that is preferred or just plain works better.
Ehm Java team can you work on this by chance? Or should we remove it?
(In reply to comment #7) > Ehm Java team can you work on this by chance? Or should we remove it? Bug 423459 is caused by using an 1.7 jdk and could easily be fixed. jdic is still missing from tree though and as it looks won't ever make it into tree anymore unless someone puts in quite some work. I mean into jdic and not the ebuild itself. As for the other deps, they are there but sometimes only newer ones than required it seems. The build.xml is beyond help and needs to be replaced or removed. How the jar is packaged is another QA violation. Etc., etc. Long story short, I see no hope to get this to fully adhere to QA standards anytime soon. Last release was 2006. So if there is a replacement, treecleaning would make sense to me. Your call.
(In reply to comment #8) > (In reply to comment #7) > > Ehm Java team can you work on this by chance? Or should we remove it? > > Bug 423459 is caused by using an 1.7 jdk and could easily be fixed. > > jdic is still missing from tree though and as it looks won't ever make it > into tree anymore unless someone puts in quite some work. I mean into jdic > and not the ebuild itself. As for the other deps, they are there but > sometimes only newer ones than required it seems. The build.xml is beyond > help and needs to be replaced or removed. How the jar is packaged is another > QA violation. Etc., etc. > > Long story short, I see no hope to get this to fully adhere to QA standards > anytime soon. Last release was 2006. So if there is a replacement, > treecleaning would make sense to me. Your call.
dropped
