Package naming structure

Hi folks,
Now that we have had HANA for almost two years and our content offering has matured we are taking a look at our package naming conventions and pros and cons to our current package layout. For example we have organized all of our content based upon functional area; ie: FI, PP, SD, MM, etc and finally MD for all of our master data (mostly attribute type views). I was just wondering how some of you are laying out your packages? Are you organizing like this or something similar? The pro for this method is if you want to find all your sales related views you can look in SD package however some projects cross multiple functional areas and that's sometimes the con for this method, it can be cumbersome to identify all of the different views that were related to the original project for example. Just wondering how others are doing this.
Thanks,
-Patrick

There was nothing wrong with CS6 in this situation, it was that the package name of the specific extension I was trying to use that was horribly named, to the point you had to repeat the class name twice, which means most developers would only put it once and it wouldn't work. Being that this was the first native extension I tried to run, it seemed that the native extension feature didn't work.
Say your name is Bob Smith and you make a native extension that runs your hardware camera as a flashlight.
If you name the class FlashLight and the package name com.bobsmith.nativeExtensions.FlashLight
people would have to put
import com.bobsmith.nativeExtensions.FlashLight.FlashLight;
or
import com.bobsmith.nativeExtensions.FlashLight.*;
to import it. And that woudldn't make much sense. "FlashLight" is the name of the class. If the class and the package subdirectory have the exact same name, people are going to think the package subdirectory is the class.
Most people trying to import it would put
import com.bobsmith.nativeExtensions.FlashLight;
or
import com.bobsmith.nativeExtensions.*;
in which case it wounld not work.
A non-insane way to name your package would be com.bobsmith.nativeExtensions.hardware
Then one could put
import com.bobsmith.nativeExtensions.hardware.FlashLight;
or
import com.bobsmith.nativeExtensions.hardware.*;
That would make sense, either importing the FlashLight hardware feature or all hardware features in the package.

Similar Messages

Best practices for package directory structure?

I've only compiled a few java programs & while I find the language itself very easy to adapt to from C++ and Javascript, I get confused about the directory structure and classpaths & such.
My main method of operation is to build small tools and test projects, and I would like to follow good practices for organizing my directory structure, so it will (a) work well with java, and (b) work well with my source control software.
Let's say I am developing packages named "com.example.test.test1", "com.example.test.test2", "com.example.tools.flapper", and "com.example.tools.spinner".
I know I can use this structure:
/java/test/test1/com/example/test/test1/* (files for com.example.test.test1 including test1.java)
/java/test/test2/com/example/test/test2/* (files for com.example.test.test2 including test2.java)
/java/tools/flapper/com/example/tools/flapper/* (files for com.example.tools.flapper including flapper.java)
/java/tools/spinner/com/example/tools/spinner/* (files for com.example.tools.spinner including spinner.java)
But the directories seem unnecessarily deep & lead to a hassle in source control that makes it difficult to browse.
Can I use this? and if so, how do I run "javac" and "jar" properly to compile/jar-ify each package?
/java/com/example/test/test1/* (files for com.example.test.test1)
/java/com/example/test/test2/* (files for com.example.test.test2)
/java/com/example/tools/flapper/* (files for com.example.tools.flapper)
/java/com/example/tools/spinner/* (files for com.example.tools.spinner)
also is it recommended to leave the .class files in the same dirs as the .java files, or better to have a separate tree for compiled .class files?

hmm, there's a lot to absorb here...
I found these articles online that seem good:
http://www.onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.html
http://www.kevinboone.com/classpath.html
I'd like to use ant if possible & understand it; I've had troubles with IDEs in the past and would like to just stick with basic build mechanisms.
I guess as a practical example let's say I have two different applications that use the serial port, that I want to release separately, each in separate .jar files. One is called com.example.applications.serial1 and the other is com.example.applications.serial2. They both use rxtx.org's gnu.io.* libraries. Serial1 uses some packages that I have developed: com.example.tools.spinner and com.example.tools.flapper, whereas Serial2 uses com.example.tools.spinner and com.example.tools.flopper
I think I want to organize things this way: (everything below under /java/src/)
com
example
applications
serial1
serial1.java
serial2
serial2.java
tools
spinner
spinner.java
flapper
flapper.java
flopper
flopper.java
and I think I want to compile to /java/classes/:
com
example
applications
serial1
serial1.class
serial2
serial2.class
tools
spinner
spinner.class
flapper
flapper.class
flopper
flopper.class
but I'm sort of lost on where to put the ant buildfiles, which directories to be in to run javac, and how to get the jar files right. From what I've searched for online, the external libraries (RXTX's jar files & .dlls for windows) are "interesting", and the easiest thing is to tell users of my .jar files to put the rxtx libs in the same library as the .jar files so I can set the Class-Path: in the .jar manifest to point to them.

Preferred package naming conventions for plug-ins?

Every combination seems to be in use already...
VIM plug-ins are vim-plugin_name
XFCE plug-ins are xfce4-plugin_name-plugin
GIMP plug-ins are (mostly) gimp-plugin-plugin_name
I plan on making some plug-in packages for a application what dose not currently have any available. So as the topic says what's preferred package naming convention? I personally like the GIMP format best but just figured I'd ask first (should really be in the guidelines IMO).

Ok well I guess I'll use the third option for now them.
While we're talking about naming conventions I was just searching for the python cairo library noticed binding library's could do with some guidance to...
cairo-perl
pycairo
ruby-rcairo
IMO language-library_name would be a nice guideline.

Cannot add package named WFSQLiteTests

I've been experiencing this problem since LR5 was released and worked with Support to try to identify the cause —but the debug tool adobe gave me didn't show what was happening during startup.
This time, I disabled all of my plugins, exited and restarted Lightroom.
These messages appeared in the System Log:
5/24/14 9:39:29.780 AM Adobe Photoshop Lightroom 5[26865]: ERROR: ForceShrinkPersistentStore_NoLock -delete- We do not have a BLOB or TEXT column type. Instead, we have 5.
5/24/14 9:39:29.819 AM Adobe Photoshop Lightroom 5[26865]: Cannot find executable for CFBundle 0x7fd8306f4210 </Users/mark/Library/Application Support/Adobe/Lightroom/Plugins/gps-proximity-jfriedl.lrplugin> (not loaded)
5/24/14 9:42:00.000 AM kernel[0]: CODE SIGNING: cs_invalid_page(0x100000000): p=27135[LogTransport2] final status 0x0, allowing (remove VALID) page
5/24/14 9:42:09.000 AM kernel[0]: CODE SIGNING: cs_invalid_page(0x100000000): p=27140[AdobeCrashDaemon] final status 0x0, allowing (remove VALID) page
5/24/14 9:42:10.374 AM Adobe Photoshop Lightroom 5[27138]: Cannot add package named WFCoreTests
Looked in /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFCoreTests.f ramework, /Applications/Adobe Photoshop Lightroom 5.app/WFCoreTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFCoreTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFCoreTests.a gtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/WFCoreTests.agtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFCoreTests.agtoolkit
!! Did you remember to add a copy frameworks step to your project?
5/24/14 9:42:10.375 AM Adobe Photoshop Lightroom 5[27138]: Cannot add package named WFSQLiteTests
Looked in /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFSQLiteTests .framework, /Applications/Adobe Photoshop Lightroom 5.app/WFSQLiteTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFSQLiteTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFSQLiteTests .agtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/WFSQLiteTests.agtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFSQLiteTests.agtoolkit
!! Did you remember to add a copy frameworks step to your project?
5/24/14 9:42:10.376 AM Adobe Photoshop Lightroom 5[27138]: Cannot add package named WFWebTests
Looked in /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFWebTests.fr amework, /Applications/Adobe Photoshop Lightroom 5.app/WFWebTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFWebTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFWebTests.ag toolkit, /Applications/Adobe Photoshop Lightroom 5.app/WFWebTests.agtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFWebTests.agtoolkit
!! Did you remember to add a copy frameworks step to your project?
5/24/14 9:42:10.376 AM Adobe Photoshop Lightroom 5[27138]: Cannot add package named WFOzClientTests
Looked in /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFOzClientTes ts.framework, /Applications/Adobe Photoshop Lightroom 5.app/WFOzClientTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFOzClientTests.framework, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WichitaFoundation.agtoolkit/Versions/A/Frameworks/WFOzClientTes ts.agtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/WFOzClientTests.agtoolkit, /Applications/Adobe Photoshop Lightroom 5.app/Contents/Frameworks/WFOzClientTests.agtoolkit
!! Did you remember to add a copy frameworks step to your project?
5/24/14 9:42:51.625 AM xpcproxy[27156]: assertion failed: 13D65: xpcproxy + 3438 [D559FC96-E6B1-363A-B850-C7AC9734F210]: 0x2
5/24/14 9:42:54.635 AM Adobe Photoshop Lightroom 5[27138]: Oops! An untagged string (assertion failed!) got thrown far enough that we display it to the user. This shouldn't happen.
I've seen the "Oops!" message on a regular bases, but the messages: "Cannot add package named WFSQLiteTests" and "!! Did you remember to add a copy frameworks step to your project?" look like pointers to the problem.
Anyone have an idea?

I have a lot of plugins that I'd accumulated over the years. And I had them active in the plugin manager even though I only use a few of them.
I never went through the exercise of moving everything out and adding them back - selectively - and checking for updates while doing so.
Some of my plugins have been abandoned by the author and most of the others have been updated (possible several times). I downloaded all of the updates and reloaded the plugins and exited Lightroom.
So far - I think the issue is resolved. The cause was an outdated plugin.
The solution is to re-evaluate the plugins you have in your Plugins and Modules folders, remove any you know you don't use, add the rest back with the Plugin Manager and check for updates.
It's OK to add back a plugin that already in the plugin manager's list. Doing so probably reloads it and highlights the plugin's name. Then you can check for updates using the "check for updates" function (found in most recent plugins) or manually, by going to the developer's web site. If you can't find the latter - remove the plugin as it's likely not current or might be abandoned.

Update existing package - naming convention/workflow questions

OK, so we have an existing package:
Adobe_CS6_MasterCollection_en_US_20120910_Install.pkg
Fast forward 1 month...
We now want to update the package so it has latest patches and so it is also renamed:
Adobe_CS6_MasterCollection_en_US_20121010_Install.pkg
How do we do this with AAMEE 3.1...there doesn't seem to be an opportuntity to rename the package.
Is it safe to simply rename the package before we begin to update it? Or can/should we rename it after we have updated it?
And what do we rename...just the *.aamee file? Or do we also need to rename the existing packge that we are updating? Before or after?
Lots of questions....
Our goal/intent is to be able to provide monthly or quarterly updates...this would require our naming convention to show correct date on the package.
Thanks,
Don

Hi,
I understand your problem about maintining the AAMEE packages without renaming them. May be a low cost solution for you right now is to add 1 more level of folder structure where you dont rename the AAMEE packages (and AAMEE package folder name) but rename its parent folder.So if you have an X.pkg made inside X folder on mac, keep this X folder inside Y folder. And you can change this Y manually after successfully updating the package to reflect current status. Doing this, you you are actually changing the path where the AAMEE package is kept on your machine but not the package itself. So you can keep modifying the current package and still maintain the version information.
I completely agree with rahul that the ability to rename the AAMEE package after modifying it is a good utility, but right now this solution may help you in maintainence.
Thanks,
Saransh Katariya | Adobe Systems | [email protected]

Rather odd problem with package naming...

Background info:
I'm working on a web-based application, on a Tomcat server. Classes (and packages) must be in a subfolder of WEB-INF/classes of the app's root. So the packages are in WEB-INF/classes/com/<package>.
The older packages are in com/gestion (for the package com.gestion ) and the newer ones are in com/incsolution/<various> where <various> can be either chart, util or pgm - following convention more closely.
OK! We have a class called SqlBean in com.gestion, which starts off like so:package com.gestion;
import java.sql.*;
import javax.sql.*;// stock pour pooled connection c'est dans javax.sql
import javax.naming.*;
import java.io.*;
public abstract class SqlBean
    ...rest of code...
}and is used in several other objects, like TransferQBean.java, which is in the same package:
package com.gestion;
import java.sql.*;
public class TransfertQBean extends SqlBean
   ...rest of code...
}Now, i've been working (with others) on this project for 2 years now, and up until last week, there was no problem with the way things were called. Come Monday (April 11), the classes won't compile any more - gives me this error:
classes/com/gestion/TransferQBean.java [5.1] cannot resolve symbol
symbol : class SqlBean
location: class com.geastion.TransferQBean
public class TransferQBean extends SqlBean
....................................................................^
Now if i add classes to com.gestion to get...
package classes.com.gestion;
import java.sql.*;
public class TransfertQBean extends SqlBean
   rest of code...
}and same for SqlBean...
package classes.com.gestion;
import java.sql.*;
import javax.sql.*;// stock pour pooled connection c'est dans javax.sql
import javax.naming.*;
import java.io.*;
public abstract class SqlBean
   ...rest of code...
}...it works, but that's not how it's supposed to be. What puzzles me the most is how this came about suddenly.
Anyone have an idea what might be causing this? AFAIK, it's abnormal...
JH

classes/com/gestion/TransferQBean.java [5.1] cannot resolve symbol
symbol : class SqlBean
location: class com.geastion.TransferQBean
public class TransferQBean extends SqlBean
....................................................................^The solution to your problem is simply that your classpath is incorrect at compile-time. How you fix that depends on how you compile (from an IDE, from the command-line javac tool, etc). But whatever you do, don't make your solution depend on a system environment CLASSPATH variable.

Package naming and inner classes

Hi there,
I've made up the following code :
package Class1;
class i {
     i() {
          System.out.println("outer");
public class Class1 {
     static class i {
          public i() {
               System.out.println("inner");
     public static void main(String[] args) {
          i i1 = new i();
          Class1.i i2 = new Class1.i();
}that produce output :
inner
inner
which may be a suprise !!!
My question is :
Is there anyway do declare & instantiate the "i" (with "outer") class inside the Class1 class ?

that produce output :
inner
inner
which may be a suprise !!!
My question is :
Is there anyway do declare & instantiate the "i" (with
"outer") class inside the Class1 class ?This is not in the least surprising - in fact I would be 'surprised' if the outer class were referenced in preference to the local one. Stop creating problems for yourself - don't create classes named 'i' and don't declare two classes in the same package with the same names (inner classes or not) unless there is absolutely no chance of ambiguity and if they are completely private.

Package file structure seems inconsistent, what to do if library fails

If I "show package contents" on my Aperture library (I know, don't touch), I see several folders with Metadata, then a folder called Masters, and another called Previews.
Under Masters and Previews, I see images ordered by year, then month, day, then by subfolders that appear to split across project lines.
Oddly, I only see years 2010, 2009, and 2008. It doesn't appear to be assigning this to the metadata, as I see in some cases it's at least two years off. Based on the size of these folders, my guess is that it has organized based on Aperture import date. Can anyone confirm?
Also, if my library takes a turn for the worse and is not repairable, is it possible to open the package, extract projects and import them into a new library as it was under Aperture 2?

apple_enthusiast wrote:
Oddly, I only see years 2010, 2009, and 2008. It doesn't appear to be assigning this to the metadata, as I see in some cases it's at least two years off. Based on the size of these folders, my guess is that it has organized based on Aperture import date. Can anyone confirm?
In my limited tests, yes.
Also, if my library takes a turn for the worse and is not repairable, is it possible to open the package, extract projects and import them into a new library as it was under Aperture 2?
Nope. Forget almost everything you might have learned about the internal structure of the Library from Aperture 2 - the entire organisational structure is now 'virtual'.
Ian

Package naming confusion

I created a subfolder in my source folder called "library"
where I want to put a bunch of package files, each file named the
same as the package it contains. However, Flex keeps insisting that
the file be named the same as the folder containing it, or it
complains...so this means I can have only ONE file per folder,
named the same as the folder. For example, the one file in folder
"library" must be called "library". I have to import
"library.library" or "package2.package2" etc...
I must be missing something obvious. Can someone explain
this?

"ohseegee" <[email protected]> wrote in
message
news:god0lr$p5e$[email protected]..
>I created a subfolder in my source folder called
"library" where I want to
>put
> a bunch of package files, each file named the same as
the package it
> contains.
> However, Flex keeps insisting that the file be named the
same as the
> folder
> containing it, or it complains...so this means I can
have only ONE file
> per
> folder, named the same as the folder. For example, the
one file in folder
> "library" must be called "library". I have to import
"library.library" or
> "package2.package2" etc...
>
> I must be missing something obvious. Can someone explain
this?
http://flexdiary.blogspot.com/2007/08/as3-basics.html

Package Organizational Structure

Hello, I have a question about how to use packages correctly. From what I've read, it seems like packages exist purely to introduce domain to a given class and its naming. I'm probably trying to over complicate this, but I was wondering if any further thought should go into the way I organize my classes with respect to package hierarchy.
The best way I can describe this is through an example. Say I have the following packages:
artist
artist.music
artist.music.album.song
artist.acting
artist.acting.movie
I have two questions I would like to ask about this:
1) Is it appropriate to have classes in "artist.music.album.song" referencing classes in "artist.acting.movie"?
2) Would it be appropriate to have the package "artist" import the package "artist.acting"?
I have a tendency to try and limit references directed backwards up a branch, but I'm not sure this is something other people would even worry about. If there is good documentation on this anyway, please feel free to point me in that direction. I wasn't able to find anything relevant searching Google.

Focuzz@asela wrote:
Hi..,
1) Yes... [ But personally I don't like it, coz it's UGLY ]
2) Yes... [ If a class @ *artist* needs to instantiate a class @ *artist.acting* ]
Here are some references :
http://java.sun.com/docs/books/tutorial/java/package/packages.html
http://javaworkshop.sourceforge.net/chapter3.html
Cheers,
Asela.1) It is not ugly. It strongly depends on your design and your view to the classes. What if a movie needs a reference to a song? Will you put the song to some different package then just because you think it is ugly? Or if a song needs to know about the movies it is played in? Is that ugly?
2) No problem.
The main thing about packages is, that you need to think about them during your design work. There are different approaches in naming packages. Some people like to start with the model-view-controller (mcv) or model-view packages (being a good start for me), others try to cut the application in a more horizontal way. Keep on trying to cut your application in comprehensible parts and name your packages wisely.

Package naming scheme (ruby-X or X-ruby)

I have a couple of packages that I want to build and both of them follow the scheme X-ruby (mysql-ruby and ncurses-ruby). Should I leave them like this or should I call them ruby-X instead?
The reason I ask is that I thought there might be a standard but actually after looking at "pacman -Ss mysql" I am not sure since there is mysql-python and perl-dbd-mysql.

The naming scheme that Eric is pushing for is <language name>-<package>.
It's just that mysql-python hasn't been renamed to python-mysql yet.

AppX Packager: directory structure for referenced .dll(s)

I'm trying to use precompiled NuGet packages, like zlib, for WinRT Universal App development. Everything installs and compiles just fine, but running app ends up with "Unable to locate DLL" exception. Apparently, zlib.dll ends up copied into AppX\bin\v120\Win32\Debug\dynamic\cdecl
instead of just AppX. If I manually copy .dll to AppX folder, everything works as a charm.
I've set up a test solution like that:
TestDLL.Windows (a dynamic library project, referenced from TestDLLApp.Windows)
TestDLL.WindowsPhone (a dynamic library project , referenced from TestDLLApp.WindowsPhone)
TestDLL.Shared (.dll shared codebase)
TestDLLApp.Windows (a windows 8.1 app project)
TestDLLApp.WindowsPhone (a windows phone 8.1 app project)
TestDLLApp.Shared (app shared codebase)
Resources\DLL (a folder with .dll just for testing purposes)
packages (this is where installed NuGet packages go)
Observations:
TestDLL output (testdll.dll) goes into AppX folder (correct)
TestDLL referenced .dll from "Resources\DLL" folder goes into "AppX\TestDLL" (incorrect, unable to locate DLL)
TestDLL NuGet .dlls go into folder like "AppX\TestDLL\bin\v120\Win32\Debug\dynamic\cdecl" (incorrect, unable to locate DLL)
TestDLLApp referenced .dll from "Resources\DLL" folder goes into "AppX" (correct)
TestDLLApp NuGet .dlls go into folder like "AppX\bin\v120\Win32\Debug\dynamic\cdecl" (incorrect, unable to locate DLL)
What am I doing wrong? How to setup packager to output .dlls into AppX forder?

Hi James,
I'm afraid, NuGet packages are already implemented via custom build .target with conditional copy tasks:
<Target Name="zlib_redist_AfterBuild_v120_and_Win32_and_Release_and_dynamic_and_cdecl" Label="v120 and Win32 and Release and dynamic and cdecl" Condition="( $(PlatformToolset.ToLower().IndexOf('v120')) > -1 Or '$(PlatformToolset.ToLower())' == 'windowskernelmodedriver8.0' Or '$(PlatformToolset.ToLower())' == 'windowsapplicationfordrivers8.0' Or '$(PlatformToolset.ToLower())' == 'windowsusermodedriver8.0' ) And '$(Platform.ToLower())' == 'win32' And ( $(Configuration.ToLower().IndexOf('debug')) == -1 ) And '$(Linkage-zlib_redist.ToLower())' == 'dynamic' And '$(CallingConvention-zlib_redist.ToLower())' == 'cdecl'" AfterTargets="zlib_redist_AfterBuild">
<Copy SourceFiles="$(MSBuildThisFileDirectory)../..//build/native/bin/v120\Win32\Release\dynamic\cdecl\zlib.dll" DestinationFolder="$(TargetDir)" SkipUnchangedFiles="true" />
</Target>
As I understand, $(TargetDir) is a root folder of a project output. I've looked through MSBuild output and seems that one to blame is .resfiles/.pri generator task. Here's what I see in generates layout.resfiles:
TestDLL\bin\v120\Win32\Debug\dynamic\cdecl\zlib.dll
I.e. MSBuild decides internal path for each file automagically. Any way to tune that?
Interestingly enough, I've googled around and found no mentioning of this problem anywhere. Am I alone with this problem or no one uses prebuild NuGet packages in their WinRT development?

Manually upgrade packages (namely Banshee)

Good afternoon,
I've been waiting for banshee (music player) to be updated in the arch repositories to its latest version for some time (its currently flagged as out of date).
Would it be possible to upgrade banshee manually by downloading the up to date version from their website?
Also, if this is possible and I do it, if banshee is upgraded on the repositories will this take preference over my manual install?
Regards,

wonder wrote:
http://repos.archlinux.org/wsvn/package … k/PKGBUILD
@ganlu do you see any hal in dependency?
but why there is:
[root@myhost ganlu]# pacman -Sy banshee
:: Synchronizing package databases...
testing is up to date
core is up to date
extra is up to date
community is up to date
resolving dependencies...
looking for inter-conflicts...
Targets (31): libgdiplus-2.8-1 mono-2.8-1 ndesk-dbus-0.6.0-2 ndesk-dbus-glib-0.4.1-2 gtk-sharp-2-2.12.10-1 mono-addins-0.5-1
taglib-sharp-2.0.3.7-1 libart-lgpl-2.3.21-1 libgnomecanvas-2.30.2-1 hal-info-0.20091130-1 eject-2.1.5-4 dmidecode-2.10-1
hal-0.5.14-4 libgssglue-0.1-2 libtirpc-0.2.1-1 rpcbind-0.2.0-2 fam-2.7.0-14 talloc-2.0.1-1 smbclient-3.5.6-1
gnome-vfs-2.24.4-1 libbonobo-2.32.0-1 libgnome-2.32.0-1 libbonoboui-2.24.4-1 libgnomeui-2.24.4-1 gnome-sharp-2.24.1-1
podsleuth-0.6.4-1 ipod-sharp-0.8.5-1 boo-0.9.3.3457-1 mono-zeroconf-0.9.0-2 webkit-sharp-0.3-1 banshee-1.8.0-1
Total Download Size: 40.39 MB
Total Installed Size: 259.65 MB
Proceed with installation? [Y/n]

OSMF Package Naming: org.openvideoplayer | Permanence?

Hi,
This is an item of curiosity on my part ... My question being is it the intent to keep the top-level package for OSMF as org.openvideoplayer?
The FAQ at OpenSourceMediaFramework.com/faq.html discusses a bit about the relationship between OSMF and OVP ("are complementary", "ongoing alignment", "OVP for Flash will incorporate the full framework and player of the OSMF code", etc.)
Sharing the same top-level package seems to imply OSMF == OVP. And yet at here at the outset, OSMF seems to have forked the codebase (for instance, OSMF currently does not include all OVP packages/classes).
Thanks,
g

The plan is to change it. Not sure to what or when. Hopefully soon.

Native Extensions don't work in Flash CS6

Edit: Never mind.
Whoever made the native extension, despite it being a useful function, used the abominable package naming structure of:
com.coder.nativeExtensions.NameOfClass.NameOfClass
Anybody going to use it would import com.coder.nativeExtensions.NameOfClass, in which case it would not work because the name of class is also the name of an extra package directory and you have to repeat it twice which makes no sense, but it works with the class name redundantly repeated twice in the import.
I am on Flash Professional CS6. I upgraded it just so I could use Native Extensions. I have browsed and added the native extension to libraries. I have added the import statement and added the xml entry for extension ID.
If I try to run it I get "Definition could not be found" error for the package import. There is a complete lack of documentation or any way to find out why it isn't working. All I get is an unhelpful error that doesn't address the actual problem.
How do you get native extensions to work?

There was nothing wrong with CS6 in this situation, it was that the package name of the specific extension I was trying to use that was horribly named, to the point you had to repeat the class name twice, which means most developers would only put it once and it wouldn't work. Being that this was the first native extension I tried to run, it seemed that the native extension feature didn't work.
Say your name is Bob Smith and you make a native extension that runs your hardware camera as a flashlight.
If you name the class FlashLight and the package name com.bobsmith.nativeExtensions.FlashLight
people would have to put
import com.bobsmith.nativeExtensions.FlashLight.FlashLight;
or
import com.bobsmith.nativeExtensions.FlashLight.*;
to import it. And that woudldn't make much sense. "FlashLight" is the name of the class. If the class and the package subdirectory have the exact same name, people are going to think the package subdirectory is the class.
Most people trying to import it would put
import com.bobsmith.nativeExtensions.FlashLight;
or
import com.bobsmith.nativeExtensions.*;
in which case it wounld not work.
A non-insane way to name your package would be com.bobsmith.nativeExtensions.hardware
Then one could put
import com.bobsmith.nativeExtensions.hardware.FlashLight;
or
import com.bobsmith.nativeExtensions.hardware.*;
That would make sense, either importing the FlashLight hardware feature or all hardware features in the package.

Package naming structure

Similar Messages

Maybe you are looking for