OK, so I removed Obrador (unused JPEG encoder) and what we are left with is:
<srcfiles dir="${lib.dir}" includes="${naga.jar}"/>
<srcfiles dir="${lib.dir}" includes="${commons-cli.jar}"/>
<srcfiles dir="${lib.dir}" includes="JSpecView.jar"/>
and also, in code, SparshUI.
JSpecView is part of Jmol, so that's fine. Does Naga have a maven piece?
Is there any reason why someone doing the Maven port can't just take these
out themselves?
Bob
On Thu, Mar 6, 2014 at 7:00 AM, Robert Hanson <[email protected]> wrote:
> Yes, good point. SparshUI is very specialized -- I doubt there is any
> Maven artifact for that -- it is only used for one particular (old)
> multi-touch application. No need for the obrador package at all; also no
> need for netscape for the application as it doesn't have the applet files
> anyway, or needn't.
>
> So the Maven idea is that you create pieces that by themselves do not run?
>
> Bob
>
>
> On Thu, Mar 6, 2014 at 5:04 AM, Spencer Bliven <[email protected]> wrote:
>
>> If they're unused they could just be removed from the jar file. However
>> commons-cli is still a problem, since it's a fairly common package. I still
>> think it would be nice to provide a maven artifact without any of the
>> dependency classes included.
>>
>>
>> On Wed, Mar 5, 2014 at 6:20 PM, Robert Hanson <[email protected]> wrote:
>>
>>> That's a good point, for sure.
>>>
>>> Really there are almost no dependencies. Here's the whole list:
>>>
>>> commons-cli-1.0.jar -- Command Line Interface -- Application only
>>> naga.jar -- very specialized MolecularPlayground/application only
>>> netscape.jar -- JSObject / Java applet only
>>>
>>> Anything else in the jars folder is not used.
>>>
>>> Since we have gone to JavaScript none of these dependencies are accessed
>>> by the applet. The application uses a command line interface, and it allows
>>> socket communication using naga. The Java applet uses the absolute minimum
>>> of just JSObject and JSException.
>>>
>>> So what do you suggest, Spencer?
>>>
>>> Bob
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Mar 5, 2014 at 9:39 AM, Spencer Bliven <[email protected]>wrote:
>>>
>>>> Maybe this has been addressed, but I couldn't find it in the list
>>>> archives. I noticed that since 12.2.0, jmol has not listed any dependencies
>>>> in the maven pom file, but instead it includes them directly in the jar
>>>> file. This has the effect of breaking maven's dependency resolution for
>>>> project which include both jmol and its dependencies. I found that out the
>>>> hard way through some very odd classpath errors in a project that declared
>>>> a commons-cli:1.2 dependency but which was actually loading the 1.0 classes
>>>> from the jmol jar.
>>>>
>>>> I assume the reason that the dependencies were bundled together was to
>>>> allow a stand-alone jar to be distributed. This can be supported by
>>>> building two profiles: a standard jar which does not include dependencies
>>>> and that gets uploaded to the maven repo; and a distribution jar which gets
>>>> built using the maven-shade-plugin in order to include all dependencies,
>>>> and which gets distributed via the website.
>>>>
>>>> -Spencer
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>>>> Perforce.
>>>> With Perforce, you get hassle-free workflows. Merge that actually works.
>>>> Faster operations. Version large binaries. Built-in WAN optimization
>>>> and the
>>>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Jmol-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Larson-Anderson Professor of Chemistry
>>> St. Olaf College
>>> Northfield, MN
>>> http://www.stolaf.edu/people/hansonr
>>>
>>>
>>> If nature does not answer first what we want,
>>> it is better to take what answer we get.
>>>
>>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>>> Perforce.
>>> With Perforce, you get hassle-free workflows. Merge that actually works.
>>> Faster operations. Version large binaries. Built-in WAN optimization
>>> and the
>>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Jmol-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Jmol-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
