from:"Spencer Bliven"

Re: [Jmol-users] Jmol on Maven Central

2016-10-25 Thread Spencer Bliven

I wonder if it is worth noting somewhere more prominant specifically that
Jmol does not use semantic versioning. This seems to be confusing for many
developers.

On Mon, Oct 24, 2016 at 7:52 PM, Mark Williamson  wrote:

>
>
> On 24/10/16 18:22, Robert Hanson wrote:
> > It actually is not metadata. Different releases include the extension of
> > date:
> >
> > 14.6.4_2016.10.30
> >
> > is not the same version as
> >
> > 14.6.4_2016.10.22
> >
> > Sorry if that breaks a convention.
> >
>
>
> Ah, OK. Apologies; I misunderstood. Please ignore my previous comments.
>
> Thanks,
>
> Mark
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Loading MMTF programmatically

2016-08-30 Thread Spencer Bliven

Thanks Bob, that works great. I didn't know that the filename could be null
if the reader is supplied.

I doubt anyone cares about the details, but if so see
https://github.com/biojava/biojava/pull/570

-Spencer

On Mon, Aug 29, 2016 at 3:15 PM, Robert Hanson <hans...@stolaf.edu> wrote:

>
> You can now just use
>
> viewer.openReader("filename", reader)
>
> where reader is one of byte[] or BufferedInputStream or Reader
>
> I'm not catching how Jmol is fitting in there in terms of loading an MMTF
> file. How does that reading fit into BioJava's writing?
>
>
> Bob
>
>
>
> On Sun, Aug 28, 2016 at 3:48 PM, Spencer Bliven <spencer.bli...@gmail.com>
> wrote:
>
>> I have a method writeToOutputStream(Structure structure, OutputStream
>> outputStream) that does the mmtf writing. I have flexibility in what
>> type of OutputStream to use. The byte[] is accessible using a
>> ByteArrayOutputStream. If it makes more sense to pass an input stream, I
>> guess this should be possible too using PipedInputStream.
>>
>> Is this the most efficient way to communicate with Jmol given that it's
>> embedded in the same process? For instance, could I just populate some data
>> structure directly? (I might still go with MMTF, since it's fully
>> implemented already)
>>
>> -Spencer
>>
>>
>> On Fri, Aug 26, 2016 at 5:02 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>>
>>> It would be totally inconvenient to treat the byte[] mmtf data as String
>>> data.
>>> You can cache the binary data as a byte array and then pass a cache://
>>> protocol.
>>> Way better would be to pass the data as a buffered stream, but I don't
>>> think that is set up in Jmol.
>>>
>>> You have the data in what form? Full byte array? BufferedInputStream?
>>>
>>> The MMTF reader needs a javajs.api.GenericBinaryDocument.
>>> This it gets from jmol.adapter.smarter.SmarterJm
>>> olAdapter.getAtomSetCollectionFromReader.
>>>
>>> I think I can tweak viewer.loadModelFromFile to allow you to feed it a
>>> BufferedInputStream. Right now it is only set up for a java.io.Reader.
>>>
>>> Will that work for you?
>>>
>>> Bob
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 26, 2016 at 7:46 AM, Spencer Bliven <
>>> spencer.bli...@gmail.com> wrote:
>>>
>>>> I'm trying to update the way BioJava interacts with Jmol. We're
>>>> currently loading structures into Jmol by converting them to PDB format and
>>>> passing that string to JmolViewer.openStringInline(). Now that Jmol 14.6 is
>>>> available in maven, we need to move away from PDB.
>>>>
>>>> My first choice would be to use MMTF as the exchange format. Is there a
>>>> way to pass MMTF to Jmol? Resolver.determineAtomSetCollectionReader
>>>> failed (probably correctly) to recognize an MMTF binary stream when
>>>> converted to a string using the default encoding, so openStringInline()
>>>> doesn't work.
>>>>
>>>> Possibly related, the mmtf demo at http://chemapps.stolaf.edu/
>>>> jmol/jsmol/mmtf.htm gives an unrecognized file format error for me.
>>>>
>>>> -Spencer
>>>>
>>>> 
>>>> --
>>>>
>>>> ___
>>>> Jmol-users mailing list
>>>> Jmol-users@lists.sourceforge.net
>>>> 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
>>>
>>>
>>> 
>>> --
>>>
>>> ___
>>> Jmol-users mailing list
>>> Jmol-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>>
>>>
>>
>> 
>> --
>>
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> 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
>
>
> 
> --
>
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Loading MMTF programmatically

2016-08-28 Thread Spencer Bliven

I have a method writeToOutputStream(Structure structure, OutputStream
outputStream) that does the mmtf writing. I have flexibility in what type
of OutputStream to use. The byte[] is accessible using a
ByteArrayOutputStream. If it makes more sense to pass an input stream, I
guess this should be possible too using PipedInputStream.

Is this the most efficient way to communicate with Jmol given that it's
embedded in the same process? For instance, could I just populate some data
structure directly? (I might still go with MMTF, since it's fully
implemented already)

-Spencer


On Fri, Aug 26, 2016 at 5:02 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> It would be totally inconvenient to treat the byte[] mmtf data as String
> data.
> You can cache the binary data as a byte array and then pass a cache://
> protocol.
> Way better would be to pass the data as a buffered stream, but I don't
> think that is set up in Jmol.
>
> You have the data in what form? Full byte array? BufferedInputStream?
>
> The MMTF reader needs a javajs.api.GenericBinaryDocument.
> This it gets from jmol.adapter.smarter.SmarterJmolAdapter.
> getAtomSetCollectionFromReader.
>
> I think I can tweak viewer.loadModelFromFile to allow you to feed it a
> BufferedInputStream. Right now it is only set up for a java.io.Reader.
>
> Will that work for you?
>
> Bob
>
>
>
>
>
> On Fri, Aug 26, 2016 at 7:46 AM, Spencer Bliven <spencer.bli...@gmail.com>
> wrote:
>
>> I'm trying to update the way BioJava interacts with Jmol. We're currently
>> loading structures into Jmol by converting them to PDB format and passing
>> that string to JmolViewer.openStringInline(). Now that Jmol 14.6 is
>> available in maven, we need to move away from PDB.
>>
>> My first choice would be to use MMTF as the exchange format. Is there a
>> way to pass MMTF to Jmol? Resolver.determineAtomSetCollectionReader
>> failed (probably correctly) to recognize an MMTF binary stream when
>> converted to a string using the default encoding, so openStringInline()
>> doesn't work.
>>
>> Possibly related, the mmtf demo at http://chemapps.stolaf.edu/
>> jmol/jsmol/mmtf.htm gives an unrecognized file format error for me.
>>
>> -Spencer
>>
>> 
>> --
>>
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> 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
>
>
> 
> --
>
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Jmol on Maven Central

2016-08-26 Thread Spencer Bliven

Currently I need to do the release. Theoretically this should be doable
automatically, but ant isn't that well supported anymore and I was unable
to figure out the configuration yet.

Bob, I do think it would be a good idea for you to make a sonatype account
<https://issues.sonatype.org/secure/Signup!default.jspa>, if only so that
you can authorize additional maintainers if needed.

-Spencer

On Fri, Aug 26, 2016 at 2:39 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> Excellent! Thanks, Nico, Spencer, and Mark.
>
> When I update Jmol to new subversions, will this somehow happen
> automatically, or does Mark or Spencer need to watch out for that and do
> something?
>
> On Fri, Aug 26, 2016 at 5:26 AM, Mark Williamson <m...@mjw.name> wrote:
>
>> On 25/08/16 16:10, Spencer Bliven wrote:
>> > 14.6.1_2016.08.20 is released! At least that's what it says on OSS. It's
>> > not yet showing up in maven central, but I think it might just takes a
>> > few hours to sync.
>> >
>> > Mark, thanks so much for sharing your build notes! They were essential
>>
>> Dear Spencer,
>>
>> Apologies for the recently quietness. Thank you for completing this; it
>> is of tremendous use.
>>
>> I tested an hour ago and I was able pull the new jmol jar down from
>> Maven central via an updated pom in another project. It all works.
>>
>> Best,
>>
>> Mark
>>
>>
>>
>> 
>> --
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> 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
>
>
> 
> --
>
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Loading MMTF programmatically

2016-08-26 Thread Spencer Bliven

I'm trying to update the way BioJava interacts with Jmol. We're currently
loading structures into Jmol by converting them to PDB format and passing
that string to JmolViewer.openStringInline(). Now that Jmol 14.6 is
available in maven, we need to move away from PDB.

My first choice would be to use MMTF as the exchange format. Is there a way
to pass MMTF to Jmol? Resolver.determineAtomSetCollectionReader failed
(probably correctly) to recognize an MMTF binary stream when converted to a
string using the default encoding, so openStringInline() doesn't work.

Possibly related, the mmtf demo at
http://chemapps.stolaf.edu/jmol/jsmol/mmtf.htm gives an unrecognized file
format error for me.

-Spencer
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Jmol on Maven Central

2016-08-25 Thread Spencer Bliven

14.6.1_2016.08.20 is released! At least that's what it says on OSS. It's
not yet showing up in maven central, but I think it might just takes a few
hours to sync.

Mark, thanks so much for sharing your build notes! They were essential to
me. I will add a few more notes for future reference:



> Preamble
> -
> 0) Start with a 64 bit install of Ubuntu 14.04.4
>
> 1) Install the following packages
>sudo apt-get install mvn libsaxon-java openjdk-7-jdk ant
>
> 2) Create ~/.jmol.build.properties file with contents
>
>

3) Add your credentials to ~/.m2/settings.xml. This should include both OSS
user/password and a GPG key. Note that GPG is used to sign the full
release, in addition to the JKS self-signature configured in
~/.jmol.build.properties




sonatype-nexus-snapshots
OSS_USERNAME
OSS_PASSWORD


sonatype-nexus-staging
OSS_USERNAME
OSS_PASSWORD


releases
OSS_USERNAME
OSS_PASSWORD




gpg

GPG_KEY
GPG_PASSWORD







Main


1) Checkout the source from SVN or switch to the correct branch

svn checkout http://svn.code.sf.net/p/jmol/code/branches/v14_6 jmol-code
cd jmol-code/Jmol



> 2) Add a required jar to enable docs to be built
>mv ./unused/saxon.jar ./jars/
>
> 3) Build jar target
>ant jar
>
>
> 4) Build dist target
>ant dist
>
>
>
Note that this succeeds for me with an SVN checkout.

You should now have a build/dist-maven directory with the pom and jar files.

5) Stage to OSS

   ant -f ./tools/jmol-sonatype.xml dist-release


(I assume that patch 33  will
be merged in before the next release

6) Go to https://oss.sonatype.org/, find the newly staged release, and
manually 'Close' and 'Release' it. This process should be automatable, but
the 'nexus' plugin referenced in the 'close-release' and 'promote-release'
ant targets is no longer available, and I wasn't able to get its
replacement, the nexus-staging-maven-plugin
, to
work right.
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Jmol on Maven Central

2016-08-25 Thread Spencer Bliven

Thanks a lot, Nico!

On Wed, Aug 24, 2016 at 6:22 PM, Nicolas Vervelle <nverve...@gmail.com>
wrote:

> Ok,
>
> I've added a comment to request access for you.
> https://issues.sonatype.org/browse/OSSRH-3633?
> focusedCommentId=369327=com.atlassian.jira.plugin.
> system.issuetabpanels:comment-tabpanel#comment-369327
>
> Nico
>
>
> On Wed, Aug 24, 2016 at 11:12 AM, Spencer Bliven <spencer.bli...@gmail.com
> > wrote:
>
>> I volunteer to push releases to maven central. My OSS username is
>> sbliven.
>>
>> To authorize someone, I believe that it is sufficient to add a comment to
>> your OSS project ticket (https://issues.sonatype.org/browse/OSSRH-3633)
>> requesting access for the username.
>>
>> -Spencer
>>
>> On Tue, Aug 23, 2016 at 10:55 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>>
>>> not aware of any volunteers.
>>>
>>> On Tue, Aug 23, 2016 at 10:40 AM, Spencer Bliven <
>>> spencer.bli...@gmail.com> wrote:
>>>
>>>> I just wanted to bump this thread. Any chance of getting a new maven
>>>> maintainer added soon?
>>>>
>>>> Cheers,
>>>> Spencer
>>>>
>>>> On Fri, Aug 12, 2016 at 10:19 AM, Spencer Bliven <
>>>> spencer.bli...@gmail.com> wrote:
>>>>
>>>>> So I guess the next step that needs to happen is for Nico to request
>>>>> that Mark get added to the OSS ticket. I haven't been an active Jmol
>>>>> contributor, but I'd be happy to help with maintaining the maven package 
>>>>> if
>>>>> you want to add me too (OSS user sbliven).
>>>>>
>>>>> -Spencer
>>>>>
>>>>> On Thu, Aug 11, 2016 at 11:29 PM, Robert Hanson <hans...@stolaf.edu>
>>>>> wrote:
>>>>>
>>>>>> all checked in.
>>>>>>
>>>>>> On Thu, Aug 11, 2016 at 3:09 AM, Spencer Bliven <
>>>>>> spencer.bli...@gmail.com> wrote:
>>>>>>
>>>>>>> Awesome. BioJava has good mmtf support, so if we can get the new
>>>>>>> Jmol release into maven then MMTF might be a good exchange format for
>>>>>>> passing structures to Jmol. We're currently stuck with using PDB and are
>>>>>>> hurting from the limitations (e.g. on chain identifiers & number of 
>>>>>>> atoms).
>>>>>>>
>>>>>>> -Spencer
>>>>>>>
>>>>>>> On Wed, Aug 10, 2016 at 6:41 PM, Robert Hanson <hans...@stolaf.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks, Spencer. I am in the process of releasing an important
>>>>>>>> update for BioJava, as a matter of fact -- PyMOL 1.8 dump_binary PSE 
>>>>>>>> files
>>>>>>>> and the new MMTF format from RCSB (which is FANTASTIC by the way...)
>>>>>>>>
>>>>>>>> Bob
>>>>>>>>
>>>>>>>> On Wed, Aug 10, 2016 at 9:25 AM, Spencer Bliven <
>>>>>>>> spencer.bli...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hey,
>>>>>>>>>
>>>>>>>>> I also took a crack at getting the dist-release command to
>>>>>>>>> complete, since it would be extremely nice to get BioJava using a more
>>>>>>>>> recent version of Jmol. Using the latest trunk I got all steps to 
>>>>>>>>> complete
>>>>>>>>> by modifying tools/jmol-sonatype.xml as you suggest to refer to "
>>>>>>>>> ${Jmol.properties.Jmol.___JmolVersion}" in line 30. This creates
>>>>>>>>> the build/dist-maven directory as desired.
>>>>>>>>>
>>>>>>>>> Right now only Tomas (plusik) and Nico (nicov) appear to be
>>>>>>>>> authorized to upload to maven central. It would be great if some 
>>>>>>>>> additional
>>>>>>>>> people (e.g. Mark, Bob, perhaps even myself if desired) could get 
>>>>>>>>> added to
>>>>>>>>> this. Authorization is granted by adding a user to your OSS
>>>>>>>>> project ticket (https://issues.sonatype.org/browse/OSSRH-3633).
>>>>>>>&g

Re: [Jmol-users] Jmol on Maven Central

2016-08-24 Thread Spencer Bliven

I volunteer to push releases to maven central. My OSS username is sbliven.

To authorize someone, I believe that it is sufficient to add a comment to
your OSS project ticket (https://issues.sonatype.org/browse/OSSRH-3633)
requesting access for the username.

-Spencer

On Tue, Aug 23, 2016 at 10:55 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> not aware of any volunteers.
>
> On Tue, Aug 23, 2016 at 10:40 AM, Spencer Bliven <spencer.bli...@gmail.com
> > wrote:
>
>> I just wanted to bump this thread. Any chance of getting a new maven
>> maintainer added soon?
>>
>> Cheers,
>> Spencer
>>
>> On Fri, Aug 12, 2016 at 10:19 AM, Spencer Bliven <
>> spencer.bli...@gmail.com> wrote:
>>
>>> So I guess the next step that needs to happen is for Nico to request
>>> that Mark get added to the OSS ticket. I haven't been an active Jmol
>>> contributor, but I'd be happy to help with maintaining the maven package if
>>> you want to add me too (OSS user sbliven).
>>>
>>> -Spencer
>>>
>>> On Thu, Aug 11, 2016 at 11:29 PM, Robert Hanson <hans...@stolaf.edu>
>>> wrote:
>>>
>>>> all checked in.
>>>>
>>>> On Thu, Aug 11, 2016 at 3:09 AM, Spencer Bliven <
>>>> spencer.bli...@gmail.com> wrote:
>>>>
>>>>> Awesome. BioJava has good mmtf support, so if we can get the new Jmol
>>>>> release into maven then MMTF might be a good exchange format for passing
>>>>> structures to Jmol. We're currently stuck with using PDB and are hurting
>>>>> from the limitations (e.g. on chain identifiers & number of atoms).
>>>>>
>>>>> -Spencer
>>>>>
>>>>> On Wed, Aug 10, 2016 at 6:41 PM, Robert Hanson <hans...@stolaf.edu>
>>>>> wrote:
>>>>>
>>>>>> Thanks, Spencer. I am in the process of releasing an important update
>>>>>> for BioJava, as a matter of fact -- PyMOL 1.8 dump_binary PSE files and 
>>>>>> the
>>>>>> new MMTF format from RCSB (which is FANTASTIC by the way...)
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>> On Wed, Aug 10, 2016 at 9:25 AM, Spencer Bliven <
>>>>>> spencer.bli...@gmail.com> wrote:
>>>>>>
>>>>>>> Hey,
>>>>>>>
>>>>>>> I also took a crack at getting the dist-release command to complete,
>>>>>>> since it would be extremely nice to get BioJava using a more recent 
>>>>>>> version
>>>>>>> of Jmol. Using the latest trunk I got all steps to complete by modifying
>>>>>>> tools/jmol-sonatype.xml as you suggest to refer to "${Jmol
>>>>>>> .properties.Jmol.___JmolVersion}" in line 30. This creates the
>>>>>>> build/dist-maven directory as desired.
>>>>>>>
>>>>>>> Right now only Tomas (plusik) and Nico (nicov) appear to be
>>>>>>> authorized to upload to maven central. It would be great if some 
>>>>>>> additional
>>>>>>> people (e.g. Mark, Bob, perhaps even myself if desired) could get added 
>>>>>>> to
>>>>>>> this. Authorization is granted by adding a user to your OSS project
>>>>>>> ticket (https://issues.sonatype.org/browse/OSSRH-3633).
>>>>>>>
>>>>>>> Any work towards a maven release is much appreciated. Let me know if
>>>>>>> I can do anything to help with this.
>>>>>>>
>>>>>>> -Spencer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 30, 2016 at 4:39 AM, Robert Hanson <hans...@stolaf.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm not sure how ${Jmol.properties.___JmolVersion} would be  the
>>>>>>>> version number. In Build.xml it is:
>>>>>>>>
>>>>>>>>   >>>>>>> value="${Jmol.properties.Jmol.___JmolVersion}"
>>>>>>>> />
>>>>>>>>   >>>>>>> override = "true"
>>>>>>>>   input="${version}"
>>>>>>>> regexp='"'
>>>>>>>>   replace=&qu

Re: [Jmol-users] Jmol on Maven Central

2016-08-23 Thread Spencer Bliven

I just wanted to bump this thread. Any chance of getting a new maven
maintainer added soon?

Cheers,
Spencer

On Fri, Aug 12, 2016 at 10:19 AM, Spencer Bliven <spencer.bli...@gmail.com>
wrote:

> So I guess the next step that needs to happen is for Nico to request that
> Mark get added to the OSS ticket. I haven't been an active Jmol
> contributor, but I'd be happy to help with maintaining the maven package if
> you want to add me too (OSS user sbliven).
>
> -Spencer
>
> On Thu, Aug 11, 2016 at 11:29 PM, Robert Hanson <hans...@stolaf.edu>
> wrote:
>
>> all checked in.
>>
>> On Thu, Aug 11, 2016 at 3:09 AM, Spencer Bliven <spencer.bli...@gmail.com
>> > wrote:
>>
>>> Awesome. BioJava has good mmtf support, so if we can get the new Jmol
>>> release into maven then MMTF might be a good exchange format for passing
>>> structures to Jmol. We're currently stuck with using PDB and are hurting
>>> from the limitations (e.g. on chain identifiers & number of atoms).
>>>
>>> -Spencer
>>>
>>> On Wed, Aug 10, 2016 at 6:41 PM, Robert Hanson <hans...@stolaf.edu>
>>> wrote:
>>>
>>>> Thanks, Spencer. I am in the process of releasing an important update
>>>> for BioJava, as a matter of fact -- PyMOL 1.8 dump_binary PSE files and the
>>>> new MMTF format from RCSB (which is FANTASTIC by the way...)
>>>>
>>>> Bob
>>>>
>>>> On Wed, Aug 10, 2016 at 9:25 AM, Spencer Bliven <
>>>> spencer.bli...@gmail.com> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I also took a crack at getting the dist-release command to complete,
>>>>> since it would be extremely nice to get BioJava using a more recent 
>>>>> version
>>>>> of Jmol. Using the latest trunk I got all steps to complete by modifying
>>>>> tools/jmol-sonatype.xml as you suggest to refer to "${Jmol.properties.
>>>>> Jmol.___JmolVersion}" in line 30. This creates the build/dist-maven
>>>>> directory as desired.
>>>>>
>>>>> Right now only Tomas (plusik) and Nico (nicov) appear to be authorized
>>>>> to upload to maven central. It would be great if some additional people
>>>>> (e.g. Mark, Bob, perhaps even myself if desired) could get added to this. 
>>>>> Authorization
>>>>> is granted by adding a user to your OSS project ticket (
>>>>> https://issues.sonatype.org/browse/OSSRH-3633).
>>>>>
>>>>> Any work towards a maven release is much appreciated. Let me know if I
>>>>> can do anything to help with this.
>>>>>
>>>>> -Spencer
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 30, 2016 at 4:39 AM, Robert Hanson <hans...@stolaf.edu>
>>>>> wrote:
>>>>>
>>>>>> I'm not sure how ${Jmol.properties.___JmolVersion} would be  the
>>>>>> version number. In Build.xml it is:
>>>>>>
>>>>>>   >>>>> />
>>>>>>   >>>>> override = "true"
>>>>>>   input="${version}"
>>>>>> regexp='"'
>>>>>>   replace=""
>>>>>> global="true"
>>>>>>   />
>>>>>>   
>>>>>>
>>>>>>
>>>>>> So you are missing that regex process.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 25, 2016 at 9:18 AM, Mark Williamson <m...@mjw.name>
>>>>>> wrote:
>>>>>>
>>>>>>> On 17/05/16 23:15, Robert Hanson wrote:
>>>>>>> > Will be checking in Jmol 14.6 release as soon as I can. But it's
>>>>>>> not a
>>>>>>> Maven release. Someone else has to do that.
>>>>>>>
>>>>>>> Sorry for the delay in replying. I have been attempting to use the
>>>>>>> ant
>>>>>>> build script, tools/jmol-sonatype.xml, to build some artifacts for
>>>>>>> deployment to Maven central. Here is my protocol (apologies, I am not
>>>>>>> that familiar with ant and may have made some basic errors):
>>>>>>>
>>>>>>>
>>>>>>> P

Re: [Jmol-users] Jmol on Maven Central

2016-08-12 Thread Spencer Bliven

So I guess the next step that needs to happen is for Nico to request that
Mark get added to the OSS ticket. I haven't been an active Jmol
contributor, but I'd be happy to help with maintaining the maven package if
you want to add me too (OSS user sbliven).

-Spencer

On Thu, Aug 11, 2016 at 11:29 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> all checked in.
>
> On Thu, Aug 11, 2016 at 3:09 AM, Spencer Bliven <spencer.bli...@gmail.com>
> wrote:
>
>> Awesome. BioJava has good mmtf support, so if we can get the new Jmol
>> release into maven then MMTF might be a good exchange format for passing
>> structures to Jmol. We're currently stuck with using PDB and are hurting
>> from the limitations (e.g. on chain identifiers & number of atoms).
>>
>> -Spencer
>>
>> On Wed, Aug 10, 2016 at 6:41 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>>
>>> Thanks, Spencer. I am in the process of releasing an important update
>>> for BioJava, as a matter of fact -- PyMOL 1.8 dump_binary PSE files and the
>>> new MMTF format from RCSB (which is FANTASTIC by the way...)
>>>
>>> Bob
>>>
>>> On Wed, Aug 10, 2016 at 9:25 AM, Spencer Bliven <
>>> spencer.bli...@gmail.com> wrote:
>>>
>>>> Hey,
>>>>
>>>> I also took a crack at getting the dist-release command to complete,
>>>> since it would be extremely nice to get BioJava using a more recent version
>>>> of Jmol. Using the latest trunk I got all steps to complete by modifying
>>>> tools/jmol-sonatype.xml as you suggest to refer to "${Jmol.properties.
>>>> Jmol.___JmolVersion}" in line 30. This creates the build/dist-maven
>>>> directory as desired.
>>>>
>>>> Right now only Tomas (plusik) and Nico (nicov) appear to be authorized
>>>> to upload to maven central. It would be great if some additional people
>>>> (e.g. Mark, Bob, perhaps even myself if desired) could get added to this. 
>>>> Authorization
>>>> is granted by adding a user to your OSS project ticket (
>>>> https://issues.sonatype.org/browse/OSSRH-3633).
>>>>
>>>> Any work towards a maven release is much appreciated. Let me know if I
>>>> can do anything to help with this.
>>>>
>>>> -Spencer
>>>>
>>>>
>>>>
>>>> On Sat, Jul 30, 2016 at 4:39 AM, Robert Hanson <hans...@stolaf.edu>
>>>> wrote:
>>>>
>>>>> I'm not sure how ${Jmol.properties.___JmolVersion} would be  the
>>>>> version number. In Build.xml it is:
>>>>>
>>>>>   >>>> />
>>>>>   >>>> override = "true"
>>>>>   input="${version}"
>>>>> regexp='"'
>>>>>   replace=""
>>>>> global="true"
>>>>>   />
>>>>>   
>>>>>
>>>>>
>>>>> So you are missing that regex process.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 25, 2016 at 9:18 AM, Mark Williamson <m...@mjw.name> wrote:
>>>>>
>>>>>> On 17/05/16 23:15, Robert Hanson wrote:
>>>>>> > Will be checking in Jmol 14.6 release as soon as I can. But it's
>>>>>> not a
>>>>>> Maven release. Someone else has to do that.
>>>>>>
>>>>>> Sorry for the delay in replying. I have been attempting to use the ant
>>>>>> build script, tools/jmol-sonatype.xml, to build some artifacts for
>>>>>> deployment to Maven central. Here is my protocol (apologies, I am not
>>>>>> that familiar with ant and may have made some basic errors):
>>>>>>
>>>>>>
>>>>>> Preamble
>>>>>> -
>>>>>> 0) Start with a 64 bit install of Ubuntu 14.04.4
>>>>>>
>>>>>> 1) Install the following packages
>>>>>>sudo apt-get install mvn libsaxon-java openjdk-7-jdk ant
>>>>>>
>>>>>> 2) Create ~/.jmol.build.properties file with contents
>>>>>>
>>>>>>
>>>>>>
>>>>>> Main
>>>>>> 
>>>>>> 1) Obtain the source code and extract
>>>>>>wget
>>>>>

Re: [Jmol-users] Jmol on Maven Central

2016-08-11 Thread Spencer Bliven

Awesome. BioJava has good mmtf support, so if we can get the new Jmol
release into maven then MMTF might be a good exchange format for passing
structures to Jmol. We're currently stuck with using PDB and are hurting
from the limitations (e.g. on chain identifiers & number of atoms).

-Spencer

On Wed, Aug 10, 2016 at 6:41 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> Thanks, Spencer. I am in the process of releasing an important update for
> BioJava, as a matter of fact -- PyMOL 1.8 dump_binary PSE files and the new
> MMTF format from RCSB (which is FANTASTIC by the way...)
>
> Bob
>
> On Wed, Aug 10, 2016 at 9:25 AM, Spencer Bliven <spencer.bli...@gmail.com>
> wrote:
>
>> Hey,
>>
>> I also took a crack at getting the dist-release command to complete,
>> since it would be extremely nice to get BioJava using a more recent version
>> of Jmol. Using the latest trunk I got all steps to complete by modifying
>> tools/jmol-sonatype.xml as you suggest to refer to "${Jmol.properties.
>> Jmol.___JmolVersion}" in line 30. This creates the build/dist-maven
>> directory as desired.
>>
>> Right now only Tomas (plusik) and Nico (nicov) appear to be authorized to
>> upload to maven central. It would be great if some additional people (e.g.
>> Mark, Bob, perhaps even myself if desired) could get added to this. 
>> Authorization
>> is granted by adding a user to your OSS project ticket (
>> https://issues.sonatype.org/browse/OSSRH-3633).
>>
>> Any work towards a maven release is much appreciated. Let me know if I
>> can do anything to help with this.
>>
>> -Spencer
>>
>>
>>
>> On Sat, Jul 30, 2016 at 4:39 AM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>>
>>> I'm not sure how ${Jmol.properties.___JmolVersion} would be  the
>>> version number. In Build.xml it is:
>>>
>>>   >> />
>>>   >> override = "true"
>>>   input="${version}"
>>> regexp='"'
>>>   replace=""
>>> global="true"
>>>   />
>>>   
>>>
>>>
>>> So you are missing that regex process.
>>>
>>>
>>>
>>> On Mon, Jul 25, 2016 at 9:18 AM, Mark Williamson <m...@mjw.name> wrote:
>>>
>>>> On 17/05/16 23:15, Robert Hanson wrote:
>>>> > Will be checking in Jmol 14.6 release as soon as I can. But it's not a
>>>> Maven release. Someone else has to do that.
>>>>
>>>> Sorry for the delay in replying. I have been attempting to use the ant
>>>> build script, tools/jmol-sonatype.xml, to build some artifacts for
>>>> deployment to Maven central. Here is my protocol (apologies, I am not
>>>> that familiar with ant and may have made some basic errors):
>>>>
>>>>
>>>> Preamble
>>>> -
>>>> 0) Start with a 64 bit install of Ubuntu 14.04.4
>>>>
>>>> 1) Install the following packages
>>>>sudo apt-get install mvn libsaxon-java openjdk-7-jdk ant
>>>>
>>>> 2) Create ~/.jmol.build.properties file with contents
>>>>
>>>>
>>>>
>>>> Main
>>>> 
>>>> 1) Obtain the source code and extract
>>>>wget
>>>> http://heanet.dl.sourceforge.net/project/jmol/Jmol/Version%2
>>>> 014.6/Version%2014.6.1/Jmol-14.6.1_2016.07.11-full.tar.gz
>>>>
>>>>tar xfvz Jmol-14.6.1_2016.07.11-full.tar.gz
>>>>cd jmol-14.6.1_2016.07.11
>>>>
>>>> 2) Add a required jar to enable docs to be built
>>>>cp /usr/share/java/saxon.jar ./jars/
>>>>
>>>> 3) Build jar target
>>>>ant jar
>>>>
>>>>
>>>> 4) Build dist target
>>>>ant dist
>>>>
>>>>
>>>> This fails with an error stating that “srcjsv does not exist” and this
>>>> is because I do not have the source to JSpecView in the tree. However,
>>>> if I should omit the line 1216 in build.xml, for the sake of reaching
>>>> the next step:
>>>>
>>>>   
>>>>
>>>> And proceed to this:
>>>>
>>>>ant -f ./tools/jmol-sonatype.xml dist-release
>>>>
>>>> Then, the following error is seen:
>>>> BUILD FAILED
>>>> /home/mw529/code/jmol/dev/jmol-14

Re: [Jmol-users] Jmol on Maven Central

2016-08-10 Thread Spencer Bliven

Hey,

I also took a crack at getting the dist-release command to complete, since
it would be extremely nice to get BioJava using a more recent version of
Jmol. Using the latest trunk I got all steps to complete by modifying tools/
jmol-sonatype.xml as you suggest to refer to
"${Jmol.properties.Jmol.___JmolVersion}"
in line 30. This creates the build/dist-maven directory as desired.

Right now only Tomas (plusik) and Nico (nicov) appear to be authorized to
upload to maven central. It would be great if some additional people (e.g.
Mark, Bob, perhaps even myself if desired) could get added to this.
Authorization
is granted by adding a user to your OSS project ticket (
https://issues.sonatype.org/browse/OSSRH-3633).

Any work towards a maven release is much appreciated. Let me know if I can
do anything to help with this.

-Spencer



On Sat, Jul 30, 2016 at 4:39 AM, Robert Hanson  wrote:

> I'm not sure how ${Jmol.properties.___JmolVersion} would be  the version
> number. In Build.xml it is:
>
>/>
>override = "true"
>   input="${version}"
> regexp='"'
>   replace=""
> global="true"
>   />
>   
>
>
> So you are missing that regex process.
>
>
>
> On Mon, Jul 25, 2016 at 9:18 AM, Mark Williamson  wrote:
>
>> On 17/05/16 23:15, Robert Hanson wrote:
>> > Will be checking in Jmol 14.6 release as soon as I can. But it's not a
>> Maven release. Someone else has to do that.
>>
>> Sorry for the delay in replying. I have been attempting to use the ant
>> build script, tools/jmol-sonatype.xml, to build some artifacts for
>> deployment to Maven central. Here is my protocol (apologies, I am not
>> that familiar with ant and may have made some basic errors):
>>
>>
>> Preamble
>> -
>> 0) Start with a 64 bit install of Ubuntu 14.04.4
>>
>> 1) Install the following packages
>>sudo apt-get install mvn libsaxon-java openjdk-7-jdk ant
>>
>> 2) Create ~/.jmol.build.properties file with contents
>>
>>
>>
>> Main
>> 
>> 1) Obtain the source code and extract
>>wget
>> http://heanet.dl.sourceforge.net/project/jmol/Jmol/Version%2
>> 014.6/Version%2014.6.1/Jmol-14.6.1_2016.07.11-full.tar.gz
>>
>>tar xfvz Jmol-14.6.1_2016.07.11-full.tar.gz
>>cd jmol-14.6.1_2016.07.11
>>
>> 2) Add a required jar to enable docs to be built
>>cp /usr/share/java/saxon.jar ./jars/
>>
>> 3) Build jar target
>>ant jar
>>
>>
>> 4) Build dist target
>>ant dist
>>
>>
>> This fails with an error stating that “srcjsv does not exist” and this
>> is because I do not have the source to JSpecView in the tree. However,
>> if I should omit the line 1216 in build.xml, for the sake of reaching
>> the next step:
>>
>>   
>>
>> And proceed to this:
>>
>>ant -f ./tools/jmol-sonatype.xml dist-release
>>
>> Then, the following error is seen:
>> BUILD FAILED
>> /home/mw529/code/jmol/dev/jmol-14.6.1_2016.07.11/tools/jmol-
>> sonatype.xml:91:
>> Warning: Could not find file
>> /home/mw529/code/jmol/dev/jmol-14.6.1_2016.07.11/build/dist/
>> jmol-${Jmol.properties.___JmolVersion}-javadoc.jar
>> to copy.
>>
>>
>> I am guessing that this seems to be some form of mis-parsing of the
>> Jmol.properties.___JmolVersion in the build/dist directory?
>>
>> Do you have any suggestions on how to resolve this?
>>
>> Thanks,
>>
>> Mark
>>
>>
>>
>> 
>> --
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning
>> reports.http://sdm.link/zohodev2dev
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> 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
>
>
> 
> --
>
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports.

Re: [Jmol-users] Apple OS X Mavericks issues

2014-09-01 Thread Spencer Bliven

As a workaround for Issue #2, I've been using an (unofficial) 64-bit
Chromium build for a while now for testing:

http://www.chrome64bit.com/index.php/google-chrome-64-bit-for-mac

I've been using 35.0.1859.0 and found it to be quite stable and suitable
for day-to-day use.

-Spencer


On Wed, Aug 20, 2014 at 1:25 PM, Robert Hanson hans...@stolaf.edu wrote:

 Issue #3  JSmol/Java applet will not run in Safari for local pages
 (Mavericks OS 10.9.4)

 Solution: Open a local page accessing the JSmol/Java and then using
 Safari...Preferences...Security, enable local file reading

 See http://sourceforge.net/p/jmol/mailman/message/31570102/

 Outcome: Reloading the page, you should get the standard alerts about
 running Java applets, then the Jmol applet will start.


 


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Jmol-users mailing list
 Jmol-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jmol-users


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Dependencies included in jar file

2014-03-24 Thread Spencer Bliven

To close up this thread, yes I'm ok with the status quo.


On Mon, Mar 10, 2014 at 9:08 PM, Robert Hanson hans...@stolaf.edu wrote:




 On Mon, Mar 10, 2014 at 11:50 AM, Spencer Bliven sbli...@ucsd.edu wrote:

 Bob,

 This should indeed be done by whoever maintains the maven port. I had
 originally assumed that this would be you, but I see I'm incorrect. Perhaps
 that person watches this list and would benefit from the following info.

 It appears that no one is distributing a Naga maven artifact. So that
 would have to be included in the jar (or separately maintained), as would
 JSpecView and SparshUI. The maintainer is currently including vecmath as
 well, which should ship with java but has an undependable API. There are a
 couple maven repos with more stable versions. Maven central has 1.3.1, and
 http://maven.geotoolkit.org distributes 1.5.2.


 vecmath is long gone. No dependency there.

 JSpecView is really part of this project.

 SparshUI code is also used - with modification.




 While adding commons-cli and vecmath as dependencies rather than
 including them in the jar is more in line with the maven philosophy, I did
 manage to work around this problem for my own project:

 1) Put jMol last in the pom's dependency list, so that tools like eclipse
 load position it last when they construct a classpath
 2) Exclude the conflicting classes manually when building distribution
 jars. I'm using the maven shade plugin, so this looks like

 plugin
   artifactIdmaven-shade-plugin/artifactId
   ...
   executionsexecution
   ...
   configurationfilters
   filter
   artifactnet.sourceforge.jmol:jmol/artifact
   excludes
   excludeorg/apache/commons/cli/**/exclude
excludejavax/vecmath/**/exclude
   /excludes
   /filter
   /filters/configuration
   /execution/executions
 /plugin


 So you are OK with how we have it now? -- no vecmath necessary; just cli,
 I think.





 -Spencer



 On Thu, Mar 6, 2014 at 2:20 PM, Robert Hanson hans...@stolaf.edu wrote:

 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 hans...@stolaf.eduwrote:

 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 sbli...@ucsd.eduwrote:

 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 hans...@stolaf.eduwrote:

 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 sbli...@ucsd.eduwrote:

  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

Re: [Jmol-users] Dependencies included in jar file

2014-03-10 Thread Spencer Bliven

Bob,

This should indeed be done by whoever maintains the maven port. I had
originally assumed that this would be you, but I see I'm incorrect. Perhaps
that person watches this list and would benefit from the following info.

It appears that no one is distributing a Naga maven artifact. So that would
have to be included in the jar (or separately maintained), as would
JSpecView and SparshUI. The maintainer is currently including vecmath as
well, which should ship with java but has an undependable API. There are a
couple maven repos with more stable versions. Maven central has 1.3.1, and
http://maven.geotoolkit.org distributes 1.5.2.

While adding commons-cli and vecmath as dependencies rather than including
them in the jar is more in line with the maven philosophy, I did manage to
work around this problem for my own project:

1) Put jMol last in the pom's dependency list, so that tools like eclipse
load position it last when they construct a classpath
2) Exclude the conflicting classes manually when building distribution
jars. I'm using the maven shade plugin, so this looks like

plugin
  artifactIdmaven-shade-plugin/artifactId
  ...
  executionsexecution
  ...
  configurationfilters
  filter
  artifactnet.sourceforge.jmol:jmol/artifact
  excludes
  excludeorg/apache/commons/cli/**/exclude
   excludejavax/vecmath/**/exclude
  /excludes
  /filter
  /filters/configuration
  /execution/executions
/plugin


-Spencer



On Thu, Mar 6, 2014 at 2:20 PM, Robert Hanson hans...@stolaf.edu wrote:

 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 hans...@stolaf.edu 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 sbli...@ucsd.edu 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 hans...@stolaf.eduwrote:

 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 sbli...@ucsd.eduwrote:

  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=122218951iu=/4140/ostg.clktrk

Re: [Jmol-users] Dependencies included in jar file

2014-03-06 Thread Spencer Bliven

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 hans...@stolaf.edu 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 sbli...@ucsd.edu 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=122218951iu=/4140/ostg.clktrk
 ___
 Jmol-users mailing list
 Jmol-users@lists.sourceforge.net
 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=122218951iu=/4140/ostg.clktrk
 ___
 Jmol-users mailing list
 Jmol-users@lists.sourceforge.net
 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=122218951iu=/4140/ostg.clktrk___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Dependencies included in jar file

2014-03-05 Thread Spencer Bliven

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=122218951iu=/4140/ostg.clktrk___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Drawing Options

2013-02-24 Thread Spencer Bliven

Robert, thanks for the tip about  set defaultDrawArrowScale (decimal). That
was exactly what I was looking for, although it would be nice to set
different scales based for different objects (or perhaps scale it based on
the width of the line).

Regarding the SCALE parameter, it seems that decimal arguments are
interpreted as angstrom units, while integer values are interpreted as
0.01Å units. So yes, SCALE 500 == 5Å diameter. DIAMETER also displays this
dichotomy, with decimal numbers in Å and integer numbers in some other
scale (approx 1Å:13). WIDTH seems to be consistently in Å, at least for ARC
commands. Are these differences between integers and floats intended, or is
that a bug?

BTW, these behaviors are still present in 13.0. Thanks for updating,
Andreas.

Thanks,

-Spencer

On Sat, Feb 23, 2013 at 3:38 AM, Angel Herráez angel.herr...@uah.es wrote:

 Robert Hanson wrote:
  draw scale 500 arc ... 5-Angstrom diameter

 500 == not 5 angstrom, I'd say ?


  *   What's the best way to draw a line without an arrow head? Use 'draw
 cylinder'?
  Yes, I think so.

 There is draw line (polyline) and draw curve, which is useful e.g. for
 arbitrary curves with several control points
 Examples (here I am using atom numbers, but you can put coordinates
 inside the braces):

 draw myLine1 line {@10} {@5} {@9}
 draw myLine2 curve {@10} {@5} {@9}

 And you can add options like line thickness or color.

 Working at least in 13.0, but also probably in 12.0




 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_feb
 ___
 Jmol-users mailing list
 Jmol-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Drawing Options

2013-02-22 Thread Spencer Bliven

I've been trying to customized some jmol scripts and I had a couple
questions.

   1. Is there an option to change the length of the arrowhead for a 'draw
   arrow' or 'draw arrow arc' command?
   2. What are the units for the 'scale' parameter for an arc? I've found
   that a value of 500 results in an arc about 1A in radius for my test
   protein, but I assume this is somehow proportionate to the input points.
   3. What's the best way to draw a line without an arrow head? Use 'draw
   cylinder'?

I'm running Jmol 12.0.22 through BioJava.

I have to say that the
documentationhttp://chemapps.stolaf.edu/jmol/docs/#drawfor the draw
command is rather confusing, since some of the modifying
options are mutually exclusive or  change meanings depending on other
options.

Thanks,

Spencer Bliven
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Loading MMTF programmatically

Re: [Jmol-users] Loading MMTF programmatically

Re: [Jmol-users] Jmol on Maven Central

[Jmol-users] Loading MMTF programmatically

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Jmol on Maven Central

Re: [Jmol-users] Apple OS X Mavericks issues

Re: [Jmol-users] Dependencies included in jar file

Re: [Jmol-users] Dependencies included in jar file

Re: [Jmol-users] Dependencies included in jar file

[Jmol-users] Dependencies included in jar file

Re: [Jmol-users] Drawing Options

[Jmol-users] Drawing Options

19 matches

Site Navigation

Mail list logo

Footer information