Hi,
* The CLASSPATH is set at only one place in the code which is
/# build the classpath
for FILE in ./*.jar; do
CLASSPATH="${CLASSPATH:+${CLASSPATH}:}$FILE"
done
CLASSPATH=/usr/share/lib/java/swt.jar:$CLASSPATH /
After the for loop, the classpath will be empty because it has searched
in /usr/share/Azureus directory where swt.jar file wont be found.And I
believe its taking the correct swt.jar from right location. I am not
understanding why this is the problem. It will be helpful if anybody
helps me to put the right classpath in that case.
* I have the newer version of SUNWswt package I had built which is not
ported yet.[The newer version of swt is 3.4.2].And I'm unsure whether it
resolves the problem.
* As suggested by Andras and others, I can try to disable the update
check entirely. This can be done by just starting the client with
classic UI. /[ with -Dforce.ui=az2 before setting -Djava.library.path].
/I am trying for other kind of solutions also for this.
Thanks
Spoorthy
George Drapeau wrote:
>
>
> Bruce Rothermal wrote:
>> So before you vote this down. How long will it take to get this bug
>> fixed. This package (vuze) is not being ported because it is an
>> interesting piece of software. It is a required mandatory package
>> needed for a project in the HPC Deployer project.
> Ahh, interesting. Well to me, that raises the bar on the quality
> standards of this package before it goes out. Seems like the
> following problems should get taken care of, then, if it's not just a
> fun app:
>
> 1) Fix the classpath problem in the package submission to correctly
> point to the installed location of SWT.
>
> 2) The SUNWswt package itself should be fixed to include browser
> support and OpenSolaris support in general. Spoorthy, you mention a
> more recent version of SWT. Do you know if that version remedies the
> problems Amanda and I experience before? And if so, do you know when
> the updated version will be part of OpenSolaris?
>
> 3) (related to #2) Either specify a dependency on Thunderbird (because
> that's where XULrunner is now) or enhance the Firefox package so that
> it distributes XULrunner componentry, upon which SWT depends for HTML
> rendering, upon which Vuze depends for correct and complete operation.
>
> 4) The dependencies issue in SourceJuicer.
>
> By the way: to make SWT complain less, I had to change an option in
> the Vuze startup script telling it where to find the XULrunner
> component in Thunderbird. Depending on how items #2 and #3 above get
> resolved, this startup script may or may not need to be modified to match.
>
> George
>>
>> Bruce
>>
>>
>> On May 13, 2009, at 8:41 AM, George Drapeau wrote:
>>
>>>
>>>
>>> Eric Reid - Sun ISV Engineering wrote:
>>>> <snip>
>>>>>
>>>>>>
>>>>>> - the app's BitTorrent upload and download capabilities worked
>>>>>> fine; it's good enough to use as a BitTorrent client, but will be
>>>>>> missing some functionality (no rendering of the Vuze HD Network
>>>>>> page since no HTML browser support since it's not in SWT on
>>>>>> OpenSolaris as far as I could tell).
>>>>> If main functionality is there but satelite functionality isnt
>>>>> working, it's good enough for /contrib. But not for other repos.
>>>> Gosh, I have a HUGE problem with this. IPS packages enforce
>>>> dependencies at install time, as do all mature packaging systems
>>>> today. The fact that SJ has a bug, IMHO, is *not* reason enough to
>>>> claim these IPS packages in /contrib are "good enough". All the
>>>> caveats in the world will not head off potential installation
>>>> experience headaches, which will then turn people off from
>>>> OpenSolaris.
>>> You've changed my mind; rather, I should have been more specific in
>>> my last message about my opinion on the Vuze / Azureus package. I
>>> would call Vuze an alpha or beta level release because it works but
>>> lacks known functionality; I can live with that, if the package
>>> submitter were to rapidly improve the package. But this whole
>>> lack-of-dependency-checking thing is a show-stopper for packages
>>> submitted via Juicer. I apologize; I completely ignored that in my
>>> most recent message, even though I mentioned it my early comments on
>>> the package.
>>>
>>> Dependencies not working: sounds like a no-go to me for any package
>>> submission that specifies package dependencies. Seems like that
>>> should get fixed, then every package submitted that specified
>>> dependencies can be re-checked easily, then they can all go
>>> through. But they shouldn't go through now.
>>>
>>> Separately, Amanda made a good point about the other Vuze package
>>> bug, not correctly specifying the path to swt.jar. That does need
>>> to be fixed before this package is ready to be released.
>>>>
>>>> I could not in good conscience give a +1 to such packages.
>>>>
>>>> I would be curious to hear the opinions of the other SW-Porters
>>>> Core Contributors.
>>>>
>>> Me, too. I think it's straightforward enough: why allow packages to
>>> be released when we know they're missing the dependency stuff? The
>>> bug will get fixed at some point, then we'll just have more packages
>>> ready to be published, but not until then. Do the other Core
>>> Contributors agree?
>>>
>>> G.
>>>
>>> _______________________________________________
>>> sw-porters-discuss mailing list
>>> sw-porters-discuss at opensolaris.org
>>> <mailto:sw-porters-discuss at opensolaris.org>
>>> http://mail.opensolaris.org/mailman/listinfo/sw-porters-discuss
>>
>
> --
> <http://www.sun.com> * George Drapeau *
> Open Source Lead, ISV Engineering
> *Sun Microsystems, Inc.*
> 16 Network Circle, M/S UMPK16-314
> Menlo Park, CA 94025 US
> Phone/Fax +1 650 786 1789
> AIM: gdeweydrapeau; Yahoo!: georgedrapeau
> *George.Drapeau at Sun.COM <mailto:George.Drapeau at Sun.COM>*
> http://blogs.sun.com/drapeau
>
