You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(35) |
Apr
(26) |
May
(46) |
Jun
(5) |
Jul
(10) |
Aug
(29) |
Sep
(39) |
Oct
(13) |
Nov
(19) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(17) |
May
|
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(4) |
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(16) |
May
(8) |
Jun
(10) |
Jul
(3) |
Aug
(32) |
Sep
(27) |
Oct
(8) |
Nov
(5) |
Dec
(1) |
2009 |
Jan
(14) |
Feb
(2) |
Mar
(12) |
Apr
(50) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(6) |
Sep
(36) |
Oct
(70) |
Nov
(51) |
Dec
(41) |
2010 |
Jan
(3) |
Feb
(6) |
Mar
(11) |
Apr
(54) |
May
(17) |
Jun
(31) |
Jul
(13) |
Aug
|
Sep
(7) |
Oct
(168) |
Nov
(58) |
Dec
(10) |
2011 |
Jan
(83) |
Feb
(25) |
Mar
(11) |
Apr
(8) |
May
(46) |
Jun
(53) |
Jul
(49) |
Aug
(117) |
Sep
(31) |
Oct
(13) |
Nov
(7) |
Dec
|
2012 |
Jan
|
Feb
(3) |
Mar
(35) |
Apr
(21) |
May
(7) |
Jun
(6) |
Jul
(8) |
Aug
(12) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(11) |
2013 |
Jan
(1) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2012-09-18 00:28:33
|
Feature Requests item #3568322, was opened at 2012-09-17 00:26 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3568322&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Hille (s84s) Assigned to: Nobody/Anonymous (nobody) Summary: Hashing function Initial Comment: The ability to create hashes automatically on file / job completion, the ability to choose which algorthms to use as standard, which to use per job, and how many are desired for use. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-09-17 17:28 Message: Hello Steve, Can you clarify a bit more what you are after here? Currently Xena generates two SHA-512 hashes which are stored inside of the xena file (one for the contents of the package:content tag and one for the exported file). I can see how it would be desirable to have the option to change the algorithm used and to have a default setting for this. When you say the ability to choose 'which to use per job' do you mean just overriding any such default setting? Also I am not really sure what you mean when you say 'how many are desired for use'? I gather from your comment that you are looking for these hashes to be in a separate file or files from the xena files. Is this the case? ---------------------------------------------------------------------- Comment By: Steve Hille (s84s) Date: 2012-09-17 00:27 Message: Also perhaps the ability to run output the file name next to the hashes into some format, even .txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3568322&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-09-17 07:28:01
|
Feature Requests item #3568322, was opened at 2012-09-17 00:26 Message generated for change (Comment added) made by s84s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3568322&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Hille (s84s) Assigned to: Nobody/Anonymous (nobody) Summary: Hashing function Initial Comment: The ability to create hashes automatically on file / job completion, the ability to choose which algorthms to use as standard, which to use per job, and how many are desired for use. ---------------------------------------------------------------------- >Comment By: Steve Hille (s84s) Date: 2012-09-17 00:27 Message: Also perhaps the ability to run output the file name next to the hashes into some format, even .txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3568322&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-09-17 07:26:44
|
Feature Requests item #3568322, was opened at 2012-09-17 00:26 Message generated for change (Tracker Item Submitted) made by s84s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3568322&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Hille (s84s) Assigned to: Nobody/Anonymous (nobody) Summary: Hashing function Initial Comment: The ability to create hashes automatically on file / job completion, the ability to choose which algorthms to use as standard, which to use per job, and how many are desired for use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3568322&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-09-06 02:28:41
|
Feature Requests item #3559673, was opened at 2012-08-19 18:31 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3559673&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements Group: None Status: Deleted Resolution: Invalid Priority: 4 >Private: Yes Submitted By: Terry O'Neill (terryoneill) Assigned to: Nobody/Anonymous (nobody) Summary: Show more status detail for normalisation step Initial Comment: The Transfer Job Normalisation step when completed will show a status message for that step of something like: 257 Data Objects normalised successfully. OR if there are failures: 6 normalisation errors. It would be desirable if more information was provided, including: - How many Data Objects were not normalised because they were already in a preservation format - How many Data Objects were not normalised because there was no target preservation format - How many Data Objects were not normalised because of a failure during normalisation ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-09-05 19:28 Message: Marked as private to check private functionality ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-08-19 18:52 Message: Assigned to wrong tracker. This was meant to be a feature request for the Digital Preservation Recorder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3559673&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-31 04:35:23
|
Feature Requests item #3230918, was opened at 2011-03-20 22:12 Message generated for change (Settings changed) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3230918&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Allan Cunliffe (acunliffe) Assigned to: Kirti Chennareddy (kirtic) Summary: Support for LibreOffice in Xena Viewer Initial Comment: Xena Stable (v5.0.0) and Xena-XML Branch (taggged bug-3187760) If Xena is to be compatible with LibreOffice, we need to be able to launch LibreOffice from the Xena Viewer. In the current version of Xena I am getting an error when I try and view an office file in LibreOffice via the Xena Viewer. Error in GUI (none in console): com.sun.star.lang.illegalArgumentException: URL seems to be an unsupported one. It appears that the button action is trying to launch OpenOffice from /usr/bin/, whereas the LibreOffice location is /opt/libreoffice/program. Perhaps the button should get the location from Xena Properties settings? ---------------------------------------------------------------------- Comment By: Kirti Chennareddy (kirtic) Date: 2012-08-30 21:10 Message: Tested on Xena 6.0.1. This issue no more exists in the new version. Libreoffice can be launched form Xena Viewer. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-08-30 19:53 Message: Assigned to Kirti for testing to see if this issue still ever occurs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3230918&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-31 04:10:11
|
Feature Requests item #3230918, was opened at 2011-03-20 22:12 Message generated for change (Comment added) made by kirtic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3230918&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 6 Private: No Submitted By: Allan Cunliffe (acunliffe) Assigned to: Kirti Chennareddy (kirtic) Summary: Support for LibreOffice in Xena Viewer Initial Comment: Xena Stable (v5.0.0) and Xena-XML Branch (taggged bug-3187760) If Xena is to be compatible with LibreOffice, we need to be able to launch LibreOffice from the Xena Viewer. In the current version of Xena I am getting an error when I try and view an office file in LibreOffice via the Xena Viewer. Error in GUI (none in console): com.sun.star.lang.illegalArgumentException: URL seems to be an unsupported one. It appears that the button action is trying to launch OpenOffice from /usr/bin/, whereas the LibreOffice location is /opt/libreoffice/program. Perhaps the button should get the location from Xena Properties settings? ---------------------------------------------------------------------- >Comment By: Kirti Chennareddy (kirtic) Date: 2012-08-30 21:10 Message: Tested on Xena 6.0.1. This issue no more exists in the new version. Libreoffice can be launched form Xena Viewer. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-08-30 19:53 Message: Assigned to Kirti for testing to see if this issue still ever occurs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3230918&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-31 02:53:30
|
Feature Requests item #3230918, was opened at 2011-03-20 22:12 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3230918&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Allan Cunliffe (acunliffe) >Assigned to: Kirti Chennareddy (kirtic) Summary: Support for LibreOffice in Xena Viewer Initial Comment: Xena Stable (v5.0.0) and Xena-XML Branch (taggged bug-3187760) If Xena is to be compatible with LibreOffice, we need to be able to launch LibreOffice from the Xena Viewer. In the current version of Xena I am getting an error when I try and view an office file in LibreOffice via the Xena Viewer. Error in GUI (none in console): com.sun.star.lang.illegalArgumentException: URL seems to be an unsupported one. It appears that the button action is trying to launch OpenOffice from /usr/bin/, whereas the LibreOffice location is /opt/libreoffice/program. Perhaps the button should get the location from Xena Properties settings? ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-08-30 19:53 Message: Assigned to Kirti for testing to see if this issue still ever occurs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3230918&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-27 05:32:48
|
Bugs item #2870531, was opened at 2009-09-29 23:50 Message generated for change (Settings changed) made by margotc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2870531&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christopher Smart (csmart) >Assigned to: Terry O'Neill (terryoneill) Summary: Windows non-admin user can't open .xena files Initial Comment: When a non-admin users opens a .xena file, the Xena installer comes up wanting to install, rather than just opening the file. ---------------------------------------------------------------------- >Comment By: margotc (margotc) Date: 2012-08-26 22:32 Message: Reassigning to Terry for fix. ---------------------------------------------------------------------- Comment By: Kirti Chennareddy (kirtic) Date: 2012-08-26 22:18 Message: Tested on Xena 6.0.1. Issue still exists. When a non-admin user double clicks on a Xena file for the first time, Xena installer comes up and then Xena viewer opens the xena file. This only happens on the first attempt. Any subsequent attempt to open a xena file does not start the installer. ---------------------------------------------------------------------- Comment By: margotc (margotc) Date: 2012-03-15 18:01 Message: Test to see if this is still occuring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2870531&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-27 05:18:01
|
Bugs item #2870531, was opened at 2009-09-29 23:50 Message generated for change (Comment added) made by kirtic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2870531&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christopher Smart (csmart) Assigned to: Kirti Chennareddy (kirtic) Summary: Windows non-admin user can't open .xena files Initial Comment: When a non-admin users opens a .xena file, the Xena installer comes up wanting to install, rather than just opening the file. ---------------------------------------------------------------------- >Comment By: Kirti Chennareddy (kirtic) Date: 2012-08-26 22:18 Message: Tested on Xena 6.0.1. Issue still exists. When a non-admin user double clicks on a Xena file for the first time, Xena installer comes up and then Xena viewer opens the xena file. This only happens on the first attempt. Any subsequent attempt to open a xena file does not start the installer. ---------------------------------------------------------------------- Comment By: margotc (margotc) Date: 2012-03-15 18:01 Message: Test to see if this is still occuring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2870531&group_id=85722 |
From: Badoo <nor...@ba...> - 2012-08-20 18:31:16
|
Un message de Gwenole Auvray t'attend... L'expéditeur et le contenu seront visibles seulement par toi et tu peux le supprimer à tout moment. Tu peux aussi y répondre directement au travers du messenger. Pour découvrir le message, suis simplement ce lien : http://eu1.badoo.com/greetz4all/in/Omd6Rh4TXuY/?lang_id=6&m=63&mid=5032826a00000000000600000042ef6a03f8f7910162 D'autres personnes à proximité qui sont sur Badoo Vatinel (Caen, France) Roxane (Caen, France) Jérémy (Caen, France) http://eu1.badoo.com/greetz4all/in/Omd6Rh4TXuY/?lang_id=6&m=63&mid=5032826a00000000000600000042ef6a03f8f7910162 Si le lien dans ce message ne fonctionne pas, essaie de le copier et de le coller dans la barre d'adresse de ton navigateur Internet. Tu as reçu cet email suite à une requête de Gwenole Auvray auprès de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système. Merci, L'équipe Badoo Vous avez reçu cet email de Badoo Trading Limited (adresse postale ci-dessous). http://eu1.badoo.com/impersonation.phtml?lang_id=6&email=xena-devel%40lists.sourceforge.net&block_code=d87d38&m=63&mid=5032826a00000000000600000042ef6a03f8f7910162 Badoo Trading Limited est une Société à Responsabilité Limitée, enregistrée en Angleterre et Pays de Galles, sous le No. 7540255, bureaux enregistrés à l’adresse 12 Red Lion Square, London, WC1R 4QD. |
From: SourceForge.net <no...@so...> - 2012-08-20 01:52:14
|
Feature Requests item #3559673, was opened at 2012-08-19 18:31 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3559673&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements Group: None >Status: Deleted >Resolution: Invalid Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Nobody/Anonymous (nobody) Summary: Show more status detail for normalisation step Initial Comment: The Transfer Job Normalisation step when completed will show a status message for that step of something like: 257 Data Objects normalised successfully. OR if there are failures: 6 normalisation errors. It would be desirable if more information was provided, including: - How many Data Objects were not normalised because they were already in a preservation format - How many Data Objects were not normalised because there was no target preservation format - How many Data Objects were not normalised because of a failure during normalisation ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-08-19 18:52 Message: Assigned to wrong tracker. This was meant to be a feature request for the Digital Preservation Recorder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3559673&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-20 01:31:39
|
Feature Requests item #3559673, was opened at 2012-08-19 18:31 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3559673&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Nobody/Anonymous (nobody) Summary: Show more status detail for normalisation step Initial Comment: The Transfer Job Normalisation step when completed will show a status message for that step of something like: 257 Data Objects normalised successfully. OR if there are failures: 6 normalisation errors. It would be desirable if more information was provided, including: - How many Data Objects were not normalised because they were already in a preservation format - How many Data Objects were not normalised because there was no target preservation format - How many Data Objects were not normalised because of a failure during normalisation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3559673&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-14 01:31:43
|
Feature Requests item #3557111, was opened at 2012-08-13 18:31 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3557111&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Nobody/Anonymous (nobody) Summary: Metadata plugin - support for different extraction programs Initial Comment: Currently the Metadata plugin is coded to work explicitly with Exiftool. It would be desirable if this was extended to support other tools that may generate metadata or scripts that may be written. This would involve allowing the user to specify the parameters sent to the metadata extraction program to some extent (an probably some control around the expected output format). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3557111&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-07 04:35:24
|
Bugs item #3551095, was opened at 2012-07-28 16:13 Message generated for change (Comment added) made by kirtic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Gary McGath (garymcgath) Assigned to: Kirti Chennareddy (kirtic) Summary: Erroneous reference to Xena Lite in error message Initial Comment: In starting up Xena.app on OS X 10.6.8, I got the error message "Cannot find default plugins directory. Try running Xena Lite from the same directory as xena.jar". This kept Tools / Plugin Preferences from working. I couldn't find anything called Xena Lite. This should probably be changed to "Xena." The relevant code seems to be in ViewerMainFrame.java. I was able to solve the problem (for the Mac OS X version) by going to the directory that held Xena.app and entering "ln -s ./macx86/plugins plugins". This was a lucky guess aided by looking at the stack dump. The installation had been working the first time, and I don't know why it stopped working. ---------------------------------------------------------------------- >Comment By: Kirti Chennareddy (kirtic) Date: 2012-08-06 21:35 Message: Tested on Xena 6.0.1 Testing branch. Error messages are displayed as per Terry's comments below. Tested ok. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-07-30 00:17 Message: Altered the error message in the Testing branch to refer to Xena rather than Xena Lite and to give the location of the directory it is looking for (and also the second possible location of the current directory if running from a different directory than that containing xena.jar). Gary, from the description it sounds like the most likely cause would be if you accidentally moved the plugins folder into the macx86 folder. They do appear next to each other in the finder window so it is easy to accidentally drag. Assigned to Kirti for testing. ---------------------------------------------------------------------- Comment By: Kirti Chennareddy (kirtic) Date: 2012-07-29 19:42 Message: Tested with the Xena 6.0.1 Mac installer. Installer puts the plugins directory in the same directory as xena.jar. Error message comes up when the Plugins directory is moved or deleted from the Xena app directory. Same error comes up on trying to open a Xena file using Xena Viewer without the plugins directory. Reinstallation should put the plugins directory back into the folder. It is the same behaviour with Linux and Windows OS. Error message has to be re-worded and reference to Xena Lite has to be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-02 00:10:39
|
Bugs item #3515030, was opened at 2012-04-04 18:11 Message generated for change (Comment added) made by wisanupp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3515030&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Wisanu Promthong (wisanupp) Assigned to: Kirti Chennareddy (kirtic) Summary: NPE when normalises the zip file with custom FileNamer Initial Comment: When we specify the ActiveFileNamer, it will cause NPE when trying to normalise the zip file. //-----Code snippet------ xena = new Xena(); //load the plugins xena.loadPlugins(new File(config.getPlugin_path())); //specify the custom FileNamer xena.setActiveFileNamer(new DAFileNamer()); // initialize inputFile and destinationDir here //must use zip file as an input to produce the error NormaliserResults res = xena.normalise(new XenaInputSource(inputFile), new File(destinationDir), true); //------End Code snippet ---- Result: java.lang.NullPointerException at au.gov.naa.digipres.xena.kernel.filenamer.AbstractFileNamer.makeNewOpenFile(AbstractFileNamer.java:110) at au.gov.naa.digipres.xena.plugin.archive.ArchiveNormaliser.parse(ArchiveNormaliser.java:113) at au.gov.naa.digipres.xena.kernel.normalise.NormaliserManager.parse(NormaliserManager.java:877) at au.gov.naa.digipres.xena.kernel.normalise.NormaliserManager.normalise(NormaliserManager.java:1255) at au.gov.naa.digipres.xena.core.Xena.normalise(Xena.java:742) at au.gov.naa.digipres.xena.core.Xena.normalise(Xena.java:610) Per my rough investigation, the root cause is the foreign FileNamer that XENA accept through setActiveFileNamer isn't get the FileNamerManger assigned (in FileNamerManager class) and subsequently case NPE when try to process the zip file. ---------------------------------------------------------------------- >Comment By: Wisanu Promthong (wisanupp) Date: 2012-08-01 17:10 Message: Thank you Terry ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-07-31 17:49 Message: Reproduced and Fixed in Testing branch. Seems that there were issues with more files than just zip files. Fixed to correctly use the assigned active file namer. Also added the method "public File makeNewOpenFile(XenaInputSource input, File destinationDir) throws XenaException" to allow for renaming files when the file would otherwise just be copied (as occurs when performing a Convert on a file that Xena does not know a way to convert or already considers a good archival format). Assigned to Kirti for testing. Kirti you may need my help to test this. Have added the class au.gov.naa.digipres.xena.core.test.CustomFileNamerTest.java for testing this issue but this is mostly hardcoded at the moment. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-07-29 19:44 Message: Thank you Wisanu. Attempting to reproduce. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3515030&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-08-01 00:49:33
|
Bugs item #3515030, was opened at 2012-04-04 18:11 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3515030&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Wisanu Promthong (wisanupp) >Assigned to: Kirti Chennareddy (kirtic) Summary: NPE when normalises the zip file with custom FileNamer Initial Comment: When we specify the ActiveFileNamer, it will cause NPE when trying to normalise the zip file. //-----Code snippet------ xena = new Xena(); //load the plugins xena.loadPlugins(new File(config.getPlugin_path())); //specify the custom FileNamer xena.setActiveFileNamer(new DAFileNamer()); // initialize inputFile and destinationDir here //must use zip file as an input to produce the error NormaliserResults res = xena.normalise(new XenaInputSource(inputFile), new File(destinationDir), true); //------End Code snippet ---- Result: java.lang.NullPointerException at au.gov.naa.digipres.xena.kernel.filenamer.AbstractFileNamer.makeNewOpenFile(AbstractFileNamer.java:110) at au.gov.naa.digipres.xena.plugin.archive.ArchiveNormaliser.parse(ArchiveNormaliser.java:113) at au.gov.naa.digipres.xena.kernel.normalise.NormaliserManager.parse(NormaliserManager.java:877) at au.gov.naa.digipres.xena.kernel.normalise.NormaliserManager.normalise(NormaliserManager.java:1255) at au.gov.naa.digipres.xena.core.Xena.normalise(Xena.java:742) at au.gov.naa.digipres.xena.core.Xena.normalise(Xena.java:610) Per my rough investigation, the root cause is the foreign FileNamer that XENA accept through setActiveFileNamer isn't get the FileNamerManger assigned (in FileNamerManager class) and subsequently case NPE when try to process the zip file. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-07-31 17:49 Message: Reproduced and Fixed in Testing branch. Seems that there were issues with more files than just zip files. Fixed to correctly use the assigned active file namer. Also added the method "public File makeNewOpenFile(XenaInputSource input, File destinationDir) throws XenaException" to allow for renaming files when the file would otherwise just be copied (as occurs when performing a Convert on a file that Xena does not know a way to convert or already considers a good archival format). Assigned to Kirti for testing. Kirti you may need my help to test this. Have added the class au.gov.naa.digipres.xena.core.test.CustomFileNamerTest.java for testing this issue but this is mostly hardcoded at the moment. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2012-07-29 19:44 Message: Thank you Wisanu. Attempting to reproduce. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3515030&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-30 07:30:56
|
Feature Requests item #3551878, was opened at 2012-07-30 00:25 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3551878&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements Group: None Status: Open >Resolution: Fixed Priority: 3 Private: No Submitted By: Terry O'Neill (terryoneill) >Assigned to: Kirti Chennareddy (kirtic) Summary: Show error dialog in viewer when giving file path on CLI Initial Comment: When running the Xena Viewer with the file to open provided as a command line argument then there is a section of code for which any errors only result in a stack trace being written but no error dialog being shown. A missing plugins directory is one such error for which this will occur. This should be altered to show a dialog for such errors otherwise users may not know what the error is. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-07-30 00:30 Message: Fixed in Testing branch and assigned to Kirti for testing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3551878&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-30 07:26:47
|
Feature Requests item #3551878, was opened at 2012-07-30 00:25 Message generated for change (Settings changed) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3551878&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) >Summary: Show error dialog in viewer when giving file path on CLI Initial Comment: When running the Xena Viewer with the file to open provided as a command line argument then there is a section of code for which any errors only result in a stack trace being written but no error dialog being shown. A missing plugins directory is one such error for which this will occur. This should be altered to show a dialog for such errors otherwise users may not know what the error is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3551878&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-30 07:25:09
|
Feature Requests item #3551878, was opened at 2012-07-30 00:25 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3551878&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: Viewer error dialog not shown when file as CLI argument Initial Comment: When running the Xena Viewer with the file to open provided as a command line argument then there is a section of code for which any errors only result in a stack trace being written but no error dialog being shown. A missing plugins directory is one such error for which this will occur. This should be altered to show a dialog for such errors otherwise users may not know what the error is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3551878&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-30 07:17:35
|
Bugs item #3551095, was opened at 2012-07-28 16:13 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gary McGath (garymcgath) >Assigned to: Kirti Chennareddy (kirtic) Summary: Erroneous reference to Xena Lite in error message Initial Comment: In starting up Xena.app on OS X 10.6.8, I got the error message "Cannot find default plugins directory. Try running Xena Lite from the same directory as xena.jar". This kept Tools / Plugin Preferences from working. I couldn't find anything called Xena Lite. This should probably be changed to "Xena." The relevant code seems to be in ViewerMainFrame.java. I was able to solve the problem (for the Mac OS X version) by going to the directory that held Xena.app and entering "ln -s ./macx86/plugins plugins". This was a lucky guess aided by looking at the stack dump. The installation had been working the first time, and I don't know why it stopped working. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-07-30 00:17 Message: Altered the error message in the Testing branch to refer to Xena rather than Xena Lite and to give the location of the directory it is looking for (and also the second possible location of the current directory if running from a different directory than that containing xena.jar). Gary, from the description it sounds like the most likely cause would be if you accidentally moved the plugins folder into the macx86 folder. They do appear next to each other in the finder window so it is easy to accidentally drag. Assigned to Kirti for testing. ---------------------------------------------------------------------- Comment By: Kirti Chennareddy (kirtic) Date: 2012-07-29 19:42 Message: Tested with the Xena 6.0.1 Mac installer. Installer puts the plugins directory in the same directory as xena.jar. Error message comes up when the Plugins directory is moved or deleted from the Xena app directory. Same error comes up on trying to open a Xena file using Xena Viewer without the plugins directory. Reinstallation should put the plugins directory back into the folder. It is the same behaviour with Linux and Windows OS. Error message has to be re-worded and reference to Xena Lite has to be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-30 02:44:18
|
Bugs item #3515030, was opened at 2012-04-04 18:11 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3515030&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Normaliser Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wisanu Promthong (wisanupp) >Assigned to: Terry O'Neill (terryoneill) Summary: NPE when normalises the zip file with custom FileNamer Initial Comment: When we specify the ActiveFileNamer, it will cause NPE when trying to normalise the zip file. //-----Code snippet------ xena = new Xena(); //load the plugins xena.loadPlugins(new File(config.getPlugin_path())); //specify the custom FileNamer xena.setActiveFileNamer(new DAFileNamer()); // initialize inputFile and destinationDir here //must use zip file as an input to produce the error NormaliserResults res = xena.normalise(new XenaInputSource(inputFile), new File(destinationDir), true); //------End Code snippet ---- Result: java.lang.NullPointerException at au.gov.naa.digipres.xena.kernel.filenamer.AbstractFileNamer.makeNewOpenFile(AbstractFileNamer.java:110) at au.gov.naa.digipres.xena.plugin.archive.ArchiveNormaliser.parse(ArchiveNormaliser.java:113) at au.gov.naa.digipres.xena.kernel.normalise.NormaliserManager.parse(NormaliserManager.java:877) at au.gov.naa.digipres.xena.kernel.normalise.NormaliserManager.normalise(NormaliserManager.java:1255) at au.gov.naa.digipres.xena.core.Xena.normalise(Xena.java:742) at au.gov.naa.digipres.xena.core.Xena.normalise(Xena.java:610) Per my rough investigation, the root cause is the foreign FileNamer that XENA accept through setActiveFileNamer isn't get the FileNamerManger assigned (in FileNamerManager class) and subsequently case NPE when try to process the zip file. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-07-29 19:44 Message: Thank you Wisanu. Attempting to reproduce. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3515030&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-30 02:42:32
|
Bugs item #3551095, was opened at 2012-07-28 16:13 Message generated for change (Comment added) made by kirtic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gary McGath (garymcgath) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous reference to Xena Lite in error message Initial Comment: In starting up Xena.app on OS X 10.6.8, I got the error message "Cannot find default plugins directory. Try running Xena Lite from the same directory as xena.jar". This kept Tools / Plugin Preferences from working. I couldn't find anything called Xena Lite. This should probably be changed to "Xena." The relevant code seems to be in ViewerMainFrame.java. I was able to solve the problem (for the Mac OS X version) by going to the directory that held Xena.app and entering "ln -s ./macx86/plugins plugins". This was a lucky guess aided by looking at the stack dump. The installation had been working the first time, and I don't know why it stopped working. ---------------------------------------------------------------------- >Comment By: Kirti Chennareddy (kirtic) Date: 2012-07-29 19:42 Message: Tested with the Xena 6.0.1 Mac installer. Installer puts the plugins directory in the same directory as xena.jar. Error message comes up when the Plugins directory is moved or deleted from the Xena app directory. Same error comes up on trying to open a Xena file using Xena Viewer without the plugins directory. Reinstallation should put the plugins directory back into the folder. It is the same behaviour with Linux and Windows OS. Error message has to be re-worded and reference to Xena Lite has to be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-28 23:13:52
|
Bugs item #3551095, was opened at 2012-07-28 16:13 Message generated for change (Tracker Item Submitted) made by garymcgath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gary McGath (garymcgath) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous reference to Xena Lite in error message Initial Comment: In starting up Xena.app on OS X 10.6.8, I got the error message "Cannot find default plugins directory. Try running Xena Lite from the same directory as xena.jar". This kept Tools / Plugin Preferences from working. I couldn't find anything called Xena Lite. This should probably be changed to "Xena." The relevant code seems to be in ViewerMainFrame.java. I was able to solve the problem (for the Mac OS X version) by going to the directory that held Xena.app and entering "ln -s ./macx86/plugins plugins". This was a lucky guess aided by looking at the stack dump. The installation had been working the first time, and I don't know why it stopped working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3551095&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-07-26 07:59:36
|
Feature Requests item #3385976, was opened at 2011-08-03 17:53 Message generated for change (Comment added) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3385976&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Plugins Group: None >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Terry O'Neill (terryoneill) Summary: plugin version numbers should not have build in master Initial Comment: The version numbers used in plugins currently are of the form: <major>.<minor>.<increment>b<build number> For example: 1.2.5b2 Build numbers should only be present in work under development and should not be present in stable releases on the master branch. Currently the build number increments with each build so any user checking out the master branch will have the plugin version changed by the build number incrementing each time they build it. ---------------------------------------------------------------------- >Comment By: Terry O'Neill (terryoneill) Date: 2012-07-26 00:59 Message: Fixed 31st August 2011. Was part of Xena 6.0.0 Release. Closing. ---------------------------------------------------------------------- Comment By: Terry O'Neill (terryoneill) Date: 2011-08-31 00:30 Message: Prepared and tested. Made a change to add a "Release" boolean attribute to the jreleaseinfo section of the build.xml and use this to determine whether to show the build number or not (this is built into the JReleaseInfo class run through ant). Currently set to false but will change to true for the release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577092&aid=3385976&group_id=85722 |
From: SourceForge.net <no...@so...> - 2012-06-12 05:48:14
|
Bugs item #3534509, was opened at 2012-06-11 22:48 Message generated for change (Tracker Item Submitted) made by terryoneill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3534509&group_id=85722 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Viewer Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Terry O'Neill (terryoneill) Assigned to: Nobody/Anonymous (nobody) Summary: Double click open of Xena Viewer has incorrect package view Initial Comment: When testing the DPR 5.1.0 release with the Xena 6.0.1 release I processed a job and then tried to open the resultant Xena files with Xena 6.0.1 with the naa.jar plugin added. The result was that when I double clicked on a Xena file the Xena Viewer would open up and open the file in the NAA Package View. However this View would say that the Xena Package was Binary Data. When I instead opened the Xena Viewer first and used the Open button to open the same Xena files then the appropriate NAA Package View for the contained type would be displayed rather than just Binary Data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=577089&aid=3534509&group_id=85722 |