[gambas2] Splitted package and testing repository available!

Just following the bug report (http://bugs.archlinux.org/task/19318), now a repository is available to test gambas2 as a splitted package.
The purpose of these packages is that it will allow the possibility to add an archlinux package generator to the gambas2 ide, avoiding to add the full list of gambas2 packages, for only installing a graphical application.
The packages are built from a default archlinux installation, so no need to get testing repository enabled, i686 and x86_64 packages are available. Just add the following lines to your pacman.conf file:
i686
[gambarch]
Server = http://gambarch.toile-libre.org/os/i686
x86_64
[gambarch]
Server = http://gambarch.toile-libre.org/os/x86_64
I hope you will find these useful. I will take a look to add gambas3 splitted svn packages.
++

zodmaner wrote:
neotuli wrote:I'm not so sure what you're talking about. It's up and running smooth
Wow! The migration is finish? Great job guys! The migration from CVS to SVN is a very large undertaking and it's great to see that you guys have finally made it. Congrats guys.
This is great news indeed! Thanks for informing us about this, neotuli.
neotuli wrote:And yeah... we see the out of date flags, we even get a little spam every time you click one of them... but we're only human.
Don't worry, we understand you.
not quite..its seems community is going to take a bit longer got left behiend

Similar Messages

Install some packages from [testing] repository

Hello Guys,
Could you suggest me how can I install and update from time to time only several packages from testing but not all of that repository?
Have a nice day,
Stas

bangkok_manouel wrote:
There are completely valid scenarii where you can use only few packages from testing (see above, the linux kernel for example). Also, using different libs versions is not a heresy (simlinking is) so there are very few comments in this thread that would have been much more constructive without the condescending tone. Or should we, from now on, consider our fellow users as all dumb in opposition to competent linux users [1] as it has always been ?
[1] http://www.archlinux.org/about/
It is NOT safe to assume that ALL readers are competent. Just browse through the forums every once in a while. Hence care should be taken in giving advise.
This is not a private club, things posted here are read by many competent Arch users and some incompetent as well. Results show up in a Google search. Even though its perfectly valid for me to wash my motherboard in water to get rid of dust, I wouldn't post that advise here without big WARNING tags. This isn't an indication that I assume all users are idiots, but simply that I know there are some who will not understand the 'ifs' associated with such a thing.

How to assign test cases to test package and test catlog?

how to assign test cases(stwb_tc) to test package(stwb_2) and test catlog(stwb_1)?

Hi
goto to transaction stwb_1 enter the text and you will a get a screen now
goto to Menu
EDIT->Nodes->insert->As subnode
on the selecting you will get the option to add a test case (stwb_tc) or a test caltalogue.
Please reward if useful..

Problem creating unit testing repository (and workaround)

I tried to create the unit testing repository with a user that had all the required system privileges granted through a different role other than RESOURCE and CONNECT roles, and who wasn't explicitely granted CREATE VIEW, but inherited it through the custom role. However the check in SQL Developer is explicitely for the RESOURCE and CONNECT roles (regardless of what privileges they have granted to them in whichever database version past, present or future) and for CREATE VIEW privilege granted direct to the user:
SELECT DECODE (roles.required_role_count + privs.required_priv_count,
               3, 1,
               0)
          AS basic_privs_granted
FROM (SELECT COUNT (*) AS required_role_count
          FROM user_role_privs
         WHERE granted_role IN ('CONNECT', 'RESOURCE')) roles,
       (SELECT COUNT (*) AS required_priv_count
          FROM USER_SYS_PRIVS
         WHERE privilege IN ('CREATE VIEW')) privsI found this SQL contained within the sqldeveloper/extensions/oracle.sqldeveloper.unit_test.jar in an XML file: oracle/dbtools/unit_test/manage_user/UserSql.xml and replaced the SQL with one that actually checks for the specific system privileges:
SELECT DECODE (required_sys_priv_count,
               10, 1,
               0)
          AS basic_privs_granted
FROM
       (SELECT COUNT(*) AS required_sys_priv_count FROM
         (SELECT privilege
            FROM role_sys_privs
           WHERE privilege IN ('CREATE CLUSTER','CREATE INDEXTYPE','CREATE OPERATOR','CREATE PROCEDURE','CREATE SEQUENCE','CREATE SESSION','CREATE TABLE','CREATE TRIGGER','CREATE TYPE','CREATE VIEW')
          UNION
          SELECT privilege
            FROM user_sys_privs
           WHERE privilege IN ('CREATE CLUSTER','CREATE INDEXTYPE','CREATE OPERATOR','CREATE PROCEDURE','CREATE SEQUENCE','CREATE SESSION','CREATE TABLE','CREATE TRIGGER','CREATE TYPE','CREATE VIEW')))This enabled me to bypass that check when creating the respository. I don't know if all these privileges are actually required by the unit testing repository or not, so maybe the above list can be reduced...
Edited by: RDB on Mar 1, 2013 2:24 PM

Hi Sai Vineeth,
First of all, I appreciate your elaborate way of framing the question. That itself helps others to comment.
On the first two questions, I am sure you'll be able to follow the answers provided and take care of your concerns.
On your question 3), an additional piece of information that should bring smile to you
Whether the Test is to happen in DEV or QAS or whatever 'System Role' is dependent on the Test Plan.
So, if you have two distinct Test Plans, one for Unit Tests and the other for Integration Tests, which should be the case, as usual, you can certainly point the System Role to DEV or QAS as required.
Feel free to pose any other query as well.
Best regards,
Srini

Split Directory Packaging and Deployment Question

Hello Rob Woollen and All,
I have a question about packaging and deployment with the "split directory structure"
in WebLogic Server 8.1.
Specifically, how does one go about deciding which classes to put in myEnterpriseApp/myWebApp/WEB-INF/classes,
versus myEnterpriseApp/myEjbModule, versus myEnterpriseApp/APP-INF/classes?
I think the answer to the first part is easy enough: if there are classes depended
on by, say, the servlets in a web app, but not depended on anywhere else in the
enterprise app, then those classes should go in WEB-INF/classes.
It's the other part of the question that gives me trouble. I use local interfaces
on my session beans. Let's say I have a domain object class returned from a session
bean method and depended on by the web app. If I put that domain object class
under myEnterpriseApp/myEjbModule, then the web app can see it by virtue of the
classloader arrangement.
But the wlcompile Ant target supposedly compiles stuff to build/APP-INF/classes.
What stuff? How does it decide? I haven't experimented and empirically observed
yet, but I couldn't find the answer in the documentation and tutorials. Is it
looking for java source files under src/myEnterpriseApp but not under myWebApp
or myEjbModule? In general, does BEA have any recommendations in this area?
Thanks,
Randy

"Randy Stafford" <[email protected]> wrote in message
news:[email protected]...
>
Hi Mark,
Thanks for the reply. I don't have 8.1 installed yet, so I can'tempirically
observe the example's behavior. But I downloaded the example andinspected the
code. It answers some, but not all, of my questions.Where to start.
In 8.1 we have made optimizations to J2EE packaging. Mostly this is about
not having to use manifest classpath's to do sharing of of common classes.
MF Cp's are a pain to configure. You put your classes in one location in
the ear and then EVERY module has to have a MF CP entry pointing to that
location, and then you actually have N number of classes loaded per module.
The mechanism to share classes across all modules is APP-INF/lib and
APP-INF/classes. The benefit is that APP-INF is shared across all modules.
So to your question below you could just put it in the EJB module, BUT if
you have mutliple EJBs that you split into seperate modules your back tot
the same issue. So APP-INF is just the simplist solution over-all.
Split-dir is a specified way to lay out disk your src files
Split-dir
From code inspection, it looks like the JSP and EJB (therefore the web appmodule
and EJB module) both depend on the AppUtils class, which is not inAPP-INF, but
rather in a directory under the enterprise app directory that does notrepresent
a web app module or EJB module. In the build file's compile target, is itthe
wlcompile task invocation that causes compilation of AppUtils.java? Or isit
the ant task invocation (with "build.appStartup" as the value of thetarget attribute)
that causes compilation of AppUtils.java due to the dependency ofApplicationStartup
on AppUtils? And what subdirectory of the build directory doesAppUtils.class
end up in?
Why not just put AppUtils.java in the EJB module? Both dependent moduleswould
still be able to see it by virtue of the classloader arrangement. Doesputting
it in outside of all dependent modules represent a convention that BEArecommends?
>
Finally, why not put applicationresource.properties in the same place asits user
AppUtils.java?
Thanks,
Randy
"Mark Griffith" <[email protected]> wrote:
Randy:
(Rob may post later, but here is my take)
"Randy Stafford" <[email protected]> wrote in message
news:[email protected]...
Hello Rob Woollen and All,
I have a question about packaging and deployment with the "split
directory
structure"
in WebLogic Server 8.1.
Specifically, how does one go about deciding which classes to put inmyEnterpriseApp/myWebApp/WEB-INF/classes,
versus myEnterpriseApp/myEjbModule, versusmyEnterpriseApp/APP-INF/classes?
I think the answer to the first part is easy enough: if there are
classes
depended
on by, say, the servlets in a web app, but not depended on anywhereelse
in the
enterprise app, then those classes should go in WEB-INF/classes.
It's the other part of the question that gives me trouble. I use localinterfaces
on my session beans. Let's say I have a domain object class returnedfrom
a session
bean method and depended on by the web app. If I put that domain
object
class
under myEnterpriseApp/myEjbModule, then the web app can see it by
virtue
of the
classloader arrangement.
But the wlcompile Ant target supposedly compiles stuff tobuild/APP-INF/classes.
What stuff? How does it decide?wlcompile has a module factory. If a directory is claimed by a module
factory then it is compiled by that specific module compiler. The rules
for
module definition follow the same J2EE formatting rules.
So:
/myejb/
would be identified as a ebj module by:
*/myejb/meta-inf/ejb-jar.xml
*/myejb/myejb.ejb (EJBGen file)
then src files (*.java) will be compiled to
$BUILD_DIR/myejb/
/myweb/
would be identifid as a web module by:
*/myweb/WEB-INF/web.xml
Also for webapps
/myweb/WEB-INF/src/*.java
will be compiled ot
$BUILD_DIR/myweb/WEB-INF/classes
We choose WEB-INF/src following the struts precedence.
So a plain old module that has noting but .java files in it will go to
$BUILD_DIR/APP-INF/classes
If you have a jar of classes that you need to share across the entire
ear,
you would check it into your src tree at:
$SRC_DIR/APP-INF/lib/mycommon.jar
You can check out an example at:
$BEA_HOME/weblogic81/samples/server/examples/src/examples/splitdir/helloWorl
dEar
Hope this helps.
cheers
mbg
I haven't experimented and empirically observed
yet, but I couldn't find the answer in the documentation and tutorials.Is it
looking for java source files under src/myEnterpriseApp but not undermyWebApp
or myEjbModule? In general, does BEA have any recommendations in thisarea?
Thanks,
Randy

How to import and test a business package

Hi All,
I have created one Business package and want to test it.
I found one blog and followed the steps, but I am not able to see any folders named 'cFolders' under 'Content Administrator->Portal Content->Migrated Content->EP 5.0->roles-cFolders' as specified in the blog.
This is the link to blog:
Step by step guide to implement Business Package for Collaboration by cFolders 2.0
Also, should I sent par files used to create iView and system along with the business package, as I have created iView using 'New From par' and iView type is 'com.sap.portal.appintegrator.sap' and system of type 'com.sap.portal.howtos.webapp' using 'New From Par'.
Pls provide me the inputs.
Thanks in advance.
regards,
bhawna
Message was edited by: bhawna

Bhawna
Try re-starting the portal J2EE engine to see whether you see the contents as mentioned.
Also to test the business package create a user and assign one of the roles mentioned and log on with that user to see the contents.
Please award points if this helps or hints.

Split subscribtion package and allocate to differe...

Hi everyone,
I'm considering buying subscription packages for members of my team. Would it be possible with skype manager to split the number of minutes and allocate them to several skype accounts?
E.g. I buy a 120 minutes package for outgoing calls to Tanzania. Would it be possible for me to split the package and to allocate 60 minutes to 2 different skype accounts? Or, must I buy a 60 minutes package for each of them?
Thanks a lot,
Louis

As you found out... you can not have multiple build functions. I always though multiple build functions == multiple PKGBUILDs.
Can you build both server and client at once?

Searching and installing packages from testing w/o editing pacman.conf

Is this possible?

tomk wrote:Installing individual packages from the testing repo is not recommended as they are likely to depend on testing versions of other packages. The only supported way of using the testing repo is to enable it at the top of the list in pacman.conf.
I don't understand why that is true.
If I enable the testing repo and update a package (pacman -S package), and if the dependencies are set correctly, the dependencies from testing needed should also be installed/updated, right?

Pkgman - a bash script for local package and PKGBUILD management

hi all,
here is a script which manages a local repository and lets you edit
PKGBUILDs and other related files, automatically generates checksums,
build packages, add them to your local repo and so on.
it also has AUR support for submitting tarballs, leaving comments, etc.
get it from here:
http://sourceforge.net/projects/pkgman/
and AUR package:
http://aur.archlinux.org/packages.php?ID=17100
you need abs, curl and pacman and optionally namcap and desktop-file-utils.
RTFM online:
http://sourceforge.net/apps/mediawiki/p … n_man_page
first of all copy the pkgman.conf and AUR.conf files from /usr/share/pkgman to ~/.config/pkgman/ or ${XDG_CONFIG_HOME}/pkgman - if ${XDG_CONFIG_HOME} is set,
edit these two files and then run
pkgman --runmefirst
pkgman doesn´t install anything. if you want it just builds the package and moves it to your local repository. install it then with pacman.
it also has no dependency handling. there are many other tools which provide this.
the main intention was to keep track of package versions, different PKGBUILD versions and own AUR submitted tarballs; also to keep a clean local repository and clean build directories.
pkgman is stable now. i´m using it for months without any issues.
however, if there are problems or feedback please post them here.
vlad
changelog:
version 2.4:
*pkgman now respects the PKGDEST and SRCDEST variables from makepkg.conf. (though it still moves the src.tar.gz and .pkg.tar.gz to package backup directory).
version 2.5:
*pkgman uses PKGDEST if SRCDEST not set in makepkg.conf.
version 2.6 -> r26:
*changed version system: version 2.6 is now r26!
*minor changes: > pkgman uses now the $SHELL variable.
> new and more comprehensible manpage description (thanks to bender02)
version r27:
*changed SRCDEST since it's only a cache dir. all files (pkg.tar.gz and src.tar.gz) go to PKGDEST.
version r28:
*added new variable ShellCommand to pkgman.conf. Default is $SHELL.
*One might use an external application (like screen or xterm) to switch to build directory and edit files simultaneously.
version r30:
*minor changes. nothing crucial
r32: *OverwriteExistingPackage isn't used anymore. one can delete it from ~/.config/pkgman/pkgman.conf.
*minor changes
version r33:
*"-l|--list" also shows installed package version and available ABS/AUR PKGBUILD version for given package.
*"-a|--abs" can now also be used with other options (like "-e")
r39: * when backing up src.tarballs it asks whether to backup the source file or not
* more detailed "--list" option - also shows if package is installed or not and available ABS/AUR version
* added prompt to clean up directory after makepkg
* when checking pkg.tar.gz also possibility to check for conflicts with files of already installed packages
* use $PAGER instead of less
* --help directly shows the manpage
* --shorthelp shows a brief usage overview
* added a custom prompt, but only when using bash (is somehow experimental - works fine here for me)
* minor internal changes
* pkgman also reads ~/.aurvote file for getting aur name and password. if one already uses aurvote then there is no need for the
~/.config/pkgman/AUR.conf file.
r40: * new manual page & rewrite of usage function
* both option "--flush" and "--flushall" were omitted in favor of the more versatile "--cleanup" option
* pkgman <packagename> checks now if <packagename> is owned by user
* backup option after each editing
* added license
* minor internal changes
r41: * just small bug fixes, nothing crucial.
r42: * more bugs fixed.
r45: * new options added:
> --listversions: list local and available versions of installed packages from LocalPackages directory
> --getownpackages: synchronize local own packages with AUR
* added new variable in pkgman.conf:
> ListOutputInPager: output of, for example, "--list" or "--own" is piped into $PAGER
* added a new optional dependency "desktop-file-utils" for validating desktop entry files
* also supports now auto-generation of sha sums not only md5
* internal fixes due to AUR interface changes:
> use of json interface
> correct parsing of package category
* added 2 proto files (located under /usr/share/pacman):
> proto.desktop: a template for *.desktop files
> PKGBUILD-lib32.proto: a template for lib32 packages for x86_64
* some code changes and fixes
r46: * added new option to pkgman.conf (AutoGenerateSums).
> if AutoGenerateSums=no then pkgman asks whether to generate checksums or not.
> if set to yes it behaves like in former versions.
r52: * "--getownpackages" with more than 100 packages works again
* added new option "--cachecopy":
For each package in CacheCopyList (new variable in pkgman.conf) get existing package from pacman's cache directory - if
CopyPkgFromCache (new variable in pkgman.conf) is set to yes - and/or create a source tarball of PKGBUILD and related files from ABS -
if CopySrcFromABS (new variable in pkgman.conf) is set to yes - and copy them to package backup directory.
* added new variables to pkgman.conf:
> "CacheCopyList=file" - batch backup file, one package per line - default location is "$HOME/.config/pkgman/package.list".
> "CopySrcFromABS=[yes|no]"
> "CopyPkgFromCache=[yes|no]"
* some bugfixes
* docs completed
* CacheCopyList should look like
package1
package2
#this is a comment
! this too
package3
!package4
r54: * renamed "--listversions" option to "--diffversions". makes more sense!
from the man page:
pkgman --diffversions
Show differing ABS/AUR versions of installed packages from LocalPackages.
r55: * minor changes.
r57: * testing release
* added a new option "--rollback":
"pkgman <packagename> --rollback" - checks http://arm.kh.nu for available package versions,
lets you choose one, fetches the package and
moves it to the <packagename> backup directory (if "--repoadd" is used).
r59: * stable release
* new option "--rollback" (see r57):
it checks http://arm.kh.nu (Arch Rollback Machine) for available package versions,
downloads chosen file and moves it to local repository (if "-r|--repoadd" is used).
* posting files/comments/etc to AUR should work now again.
r65: *stable release
* new option "-M,--meta" to create metapackages and add them and their dependencies to local repository.
it searches for deps inside the backup directories, pacman's cache and if the packages are not available, it tries to fetch the missing
dependencies from the Arch Rollback Machine site (http://arm.kh.nu).
r66: * minor fixes
r68: * some bugfixes
* "--repoadd" and "--Reporemove" now accurately removes old packages from LocalRepository
r69: * small bugfixes when listing packages with similar names
* curl retries now 5 times if connection is not established
r75: * "--cachecopy" does not try to dl sourcefiles when backing up ABS PKGBUILDs
* some work on package splitting
* further internal changes
r76: * minor mistakes with "ln" purged
r79: * mostly small changes
* "--cleanup" now also removes uninstalled packages from LocalRepository
r81 & r80: * added AUR v1.6.0 support (use more json)
* small ARM changes ("--rollback")
r85:
* pkgman supports pkg.tar.xz packages
* some code rewrite, bugs purged (hopefully)
r113:
* pkgman now supports building split packages through makepkg.
If you already use pkgman you need to rerun "pkgman --runmefirst" after updating.
* new "-t,--template" option ("pkgman <packagename> --template <alt. packagename> [--pkgbuildversion <version>] [options]").
Useful to create a new PKGBUILD and use an existing one as a template.
* new option: "--conf /path/to/alternate/conf/file" - Specify another configuration file.
* pkgman now uses ${XDG_CONFIG_HOME}/pkgman or $HOME/.config/pkgman - if first not set - as the default location for its conf files.
r116:
* check inet conection when submitting src tarballs to AUR
* some bugs
* updated manpage on sf
For further details please read the manual page.
Last edited by DonVla (2010-04-28 11:56:59)

I'm having some troubles with it (perhaps missing dependencies, and forgotten hardcoded dirs?):
jan@aconcagua 8:20PM ~ % pkgman --runmefirst
/usr/bin/pkgman: line 77: /home/jan/apps/skripte/archscripts/pkgman/share/pkgman/color.bash: No such file or directory
/usr/bin/pkgman: line 1293: initcolor: command not found
/usr/bin/pkgman: line 312: highlight: command not found
/usr/bin/pkgman: line 312: error: command not found
/usr/bin/pkgman: line 313: highlight: command not found
/usr/bin/pkgman: line 313: error: command not found
/usr/bin/pkgman: line 314: highlight: command not found
/usr/bin/pkgman: line 314: error: command not found
/usr/bin/pkgman: line 315: highlight: command not found
/usr/bin/pkgman: line 315: error: command not found
/usr/bin/pkgman: line 317: error: command not found
/usr/bin/pkgman: line 318: error: command not found
/usr/bin/pkgman: line 321: highlight: command not found
/usr/bin/pkgman: line 321: msg: command not found
/usr/bin/pkgman: line 329: list: command not found
/usr/bin/pkgman: line 332: list: command not found
/usr/bin/pkgman: line 332: list: command not found
touch: cannot touch `/bin/.pkgman.registered': Permission denied
/usr/bin/pkgman: line 332: list: command not found
/usr/bin/pkgman: line 332: list: command not found
/usr/bin/pkgman: line 332: list: command not found
/usr/bin/pkgman: line 332: list: command not found
/usr/bin/pkgman: line 332: list: command not found
/usr/bin/pkgman: line 337: msg: command not found
curl: option --output: requires parameter
curl: try 'curl --help' or 'curl --manual' for more information
^C/usr/bin/pkgman: line 209: cleanoutput: command not found
/usr/bin/pkgman: line 209: cleanoutput: command not found
(I terminated with ctrl-c).
EDIT: errors resolved by correcting the path $HOME/apps/skripte/archscripts/pkgman/share/pkgman to /usr/share/pkgman in the pkgman itself.
Last edited by bender02 (2008-05-23 01:28:58)

TOBJ entries missing from upgrade dev and test systems

Hi,
We are in the process of ECC Upgrade from 4.7 to ECC 6.0 and upgraded our dev and test systems. We missing some SAP defined object entries in TOBJ table from dev and test. Because of this some of the roles getting transport errors if the roles contain those missing objects. We tried to transport the missing entries but we don't see any provision for that. Does any one through an idea to move those missing entries from dev to test. Not sure we will get same error in production. This table updates during upgrade and may be we missed some thing in test as though we followed the same upgrade process for both systems.
Thank you
Venkat

Possibly you are no longer licensed for components which these objects are called from in their concepts.
In that case the ability to start the component objects should be removed as well.
Of course if some Z-programs checked these objects or SAP's own "package concept" extended syntax checks did not respect them then you might have problems.
This should normally only apply to manual authorization instances, as if you had upgraded the roles and regenerated them, then you would not have this problem (in the roles).
It tells us something about how you or someone else without any training have built these roles (or subsequently mucked them up...)...
When reading stuff like this, I am always of two minds...
1) SAP should make the concepts simpler and more intuitive to use without "cowboy" activities allowed by users with SAP_ALL etc.
2) Customers should bleed for their own sins for not training people appropriatly (here, faking CV's is also ma major pest!).
It is always a bit of a cat & mouse game and ends up in forums such as SDN in the long run.
Some of it might also have become "available" to be used by SAP (I believe it was the 6.20 upgrade which installed everything...).
Real bugger. I would accept it and test as best you can. You can also compare "where.used-lists" and "code scans" before and after the upgrade to see whether it is used by foreign repository objects.
The scan is more reliable here, as sometimes the object name itself is a variable from a data declaration or condition which you cannot see in the "procedural" code.
Cheers,
Julius

Creation of developement class,package and access key

COULD ANYBODY EXPLAIN about
creation of developement class,package and access key
and who will create them?

Working With Development Objects
Any component of an application program that is stored as a separate unit in the R/3 Repository is called a development object or a Repository Object. In the SAP System, all development objects that logically belong together are assigned to the same development class.
Object Lists
In the Object Navigator, development objects are displayed in object lists, which contain all of the elements in a development class, a program, global class, or function group.
Object lists show not only a hierarchical overview of the development objects in a category, but also tell you how the objects are related to each other. The Object Navigator displays object lists as a tree.
The topmost node of an object list is the development class. From here, you can navigate right down to the lowest hierarchical level of objects. If you select an object from the tree structure that itself describes an object list, the system displays just the new object list.
For example:
Selecting an Object List in the Object Navigator
To select development objects, you use a selection list in the Object Navigator. This contains the following categories:
Category
Meaning
Application hierarchy
A list of all of the development classes in the SAP System. This list is arranged hierarchically by application components, component codes, and the development classes belonging to them
Development class
A list of all of the objects in the development class
Program
A list of all of the components in an ABAP program
Function group
A list of all of the function modules and their components that are defined within a function group
Class
A list of all of the components of a global class. It also lists the superclasses of the class, and all of the inherited and redefined methods of the current class.
Internet service
A list of all of the componentse of an Internet service:
Service description, themes, language resources, HTML templates and MIME objects.
When you choose an Internet service from the tree display, the Web Application Builder is started.
See also Integrating Internet Services.
Local objects
A list of all of the local private objects of a user.
Objects in this list belong to development class $TMP and are not transported. You can display both your own local private objects and those of other users. Local objects are used mostly for testing. If you want to transport a local object, you must assign it to another development class. For further information, refer to Changing Development Classes
http://help.sap.com/saphelp_46c/helpdata/en/d1/80194b454211d189710000e8322d00/content.htm
Creating the Main Package
Use
The main package is primarily a container for development objects that belong together, in that they share the same system, transport layer, and customer delivery status. However, you must store development objects in sub-packages, not in the main package itself.
Several main packages can be grouped together to form a structure package.
Prerequisites
You have the authorization for the activity L0 (All Functions) using the S_DEVELOP authorization object.
Procedure
You create each normal package in a similar procedure to the one described below. It can then be included as a sub-package in a main package.
To create a main package:
1.       Open the Package Builder initial screen (SE21 or SPACKAGE).
2.       In the Package field, enter a name for the package that complies with the tools Naming Conventions
Within SAP itself, the name must begin with a letter from A to S, or from U to X.
3.       Choose Create.
The system displays the Create Package dialog box.
4.       Enter the following package attributes:
Short Text
Application Component
From the component hierarchy of the SAP system, choose the abbreviation for the application component to which you want to assign the new package.
Software component
Select an entry. The software component describes a set of development objects that can only be delivered in a single unit. You should assign all the sub-packages of the main package to this software component.
Exception: Sub-packages that will not be delivered to customers must be assigned to the HOMEsoftware component.
Main Package
This checkbox appears only if you have the appropriate authorization (see Prerequisites).
To indicate that the package is a main package, check this box.
5.       Choose Save.
6.       In the dialog box that appears, assign a transport request.
Result
The Change package screen displays the attributes of the new package. To display the object list for the package in the Object Navigator as well, choose from the button bar.
You have created your main package and can now define a structure within it. Generally, you will continue by adding sub-packages to the main package. They themselves will contain the package elements you have assigned.
See also
Adding Sub-Packages to the Main Package
http://help.sap.com/saphelp_nw04/helpdata/en/ea/c05d8cf01011d3964000a0c94260a5/content.htm
access key used for change standard program.
www.sap.service.com

Best Practices for Packaging and Deploying Server-Specific Configurations

We have some server-specific properties that vary for each server. We'd
like to have these properties collected together in their own properties
file (either .properties or .xml is fine).
What is the best-practices way to package and deploy an application (as an
ear file), where each server needs some specific properties?
We'd kind of like to have the server-specific properties file be stored
external to the ear on the server itself, so that the production folks can
configure each server's properties at the server. But it appears that an
application can't access a file external to the ear, or at least we can't
figure out the magic to do it. If there is a way to do this, please let me
know how.
Or do we have to build a unique ear for each server? This is possible, of
course, but we'd prefer to build one deployment package (ear), and then
ship that off to each server that is already configured for its specific
environment. We have some audit requirements where we need to ensure that
an ear that has been tested by QA is the very same ear that has been
deployed, but if we have to build one for each server, this is not
possible.
Any help or pointers would be most appreciated. If this is an old issue,
my apologies, would you please point me to any previous material to read?
I didn't see anything after searching through this group's archives.
Thanks much in advance,
Paul
Paul Hodgetts -- Principal Consultant
Agile Logic -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA

The one draw back to this is you have to go all the way back to ant and the
build system to make changes. You really want these env variables to be
late binding.
cheers
mbg
"Sai S Prasad" <[email protected]> wrote in message
news:[email protected]...
>
Paul,
I have a similar situation in our project and I don't create ear filesspecific
to the environment. I do the following:
1) Create .properties file for every environment with the same attributename
but different values in it. For example, I have phoneix.properties.NT,phoenix.properties.DEV,
phoenix.properties.QA, phoenix.properties.PROD.
2) Use Ant to compile, package and deploy the ear file
I have a .bat file in NT and .sh for Solaris that in turn calls theant.bat or
ant.sh respectively. For the wrapper batch file or shell script, you canpass
the name of the environment. The wrapper batch file will copy theappropriate
properties file to "phonenix.properties". In the ant build.xml, I alwaysrefer
to phonenix.properties which is available all the time depending on theenvironment.
>
It works great and I can't think of any other flexible way. Hope thathelps.
>
Paul Hodgetts <[email protected]> wrote:
We have some server-specific properties that vary for each server. We'd
like to have these properties collected together in their own properties
file (either .properties or .xml is fine).
What is the best-practices way to package and deploy an application (as
an
ear file), where each server needs some specific properties?
We'd kind of like to have the server-specific properties file be stored
external to the ear on the server itself, so that the production folks
can
configure each server's properties at the server. But it appears that
an
application can't access a file external to the ear, or at least we can't
figure out the magic to do it. If there is a way to do this, please
let me
know how.
Or do we have to build a unique ear for each server? This is possible,
of
course, but we'd prefer to build one deployment package (ear), and then
ship that off to each server that is already configured for its specific
environment. We have some audit requirements where we need to ensure
that
an ear that has been tested by QA is the very same ear that has been
deployed, but if we have to build one for each server, this is not
possible.
Any help or pointers would be most appreciated. If this is an old issue,
my apologies, would you please point me to any previous material to read?
I didn't see anything after searching through this group's archives.
Thanks much in advance,
Paul
Paul Hodgetts -- Principal Consultant
Agile Logic -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA

Issues distributing packages and receiving Win32 Error = 0

Within the last month or so, we've been experiencing issues distributing various packages to our DP's. There doesn't seem to be any rhyme or reason to it; it can be any combination of packages and DP's.
We've noticed that just before the Win32 error occurs, the following 4 lines usually precede the error:
UpdateStagedFile failed; 0x80070040
UpdateStagedFolderRdc failed; 0x80070040
UpdateStagedFolderRdc failed; 0x80070040
UpdateStagedFolderRdcW failed; 0x80070040
We've had an open ticket with MS for over a week now, but there hasn't been any progress.
Any light you guys could shed on this would be greatly appreciated!

This is a known issue for SCCM 2012. A official fix will be released in the near future. If you want to test instantly, contact CSS to open a case to get a test fix.
There is a KB for this issue (English not available currently)
http://support.microsoft.com/kb/2927111/fr
Juke Chou
TechNet Community Support

"conflicts/provides" problem with splitted package

I'm currently working on some brother printer packages and have the following situation:
I want to replace the not-working package brother-mfc260c in AUR, and have made two packages, brother-mfc260c-lpr (the LPR driver) and brother-mfc260c-cupswrapper (the LPR-to-CUPS wrapper), which together provide what the old package should do (or have done).
Here are the dependency specs from the new PKGBUILDs:
brother-mfc260c-lpr:
conflicts=('brother-mfc260c')
brother-mfc260c-cupswrapper:
depends=('brother-mfc260c-lpr')
conflicts=('brother-mfc260c') # This could also be omitted because its dependency already conflicts with brother-mfc260c
provides=('brother-mfc260c=1.0.1')
But pacman doesn't like it. Whether I try to install both packages at the same time, or install brother-mfc260c-lpr first, and then brother-mfc260c-cupswrapper (like below), I get the same error:
# pacman -U brother-mfc260c-cupswrapper-1.0.1_1-1-i686.pkg.tar.gz
loading package data...
checking dependencies...
error: replacing packages with -U is not supported yet
error: you can replace packages manually using -Rd and -U
error: failed to prepare transaction (conflicting dependencies)
:: brother-mfc260c-cupswrapper: conflicts with brother-mfc260c-lpr
Should I file a bug report, or is this behavior intended? If the latter case applies, how can I solve such a conflict without loss of generality?
Thanks in advance!

Profjim wrote:Can you confirm that you've already manually removed brother-mfc260c?
Sorry for not mentioning this earlier. I've never installed brother-mfc260c on my machine to begin with, because I don't even have such a printer. But I've successfully created such a package pair for the brother-mfc210c, and have read on the AUR page of the orphaned brother-mfc260c package the comment "The driver is not working... DELETE!!!", so I've made a package pair for this model in a similar style. And the brother-mfc210c package pair only works with the above mentioned provides/conflicts statements because its provides-statement has a typo which I've found after uploading it to AUR.
To make a long story short, because of these two facts (never installed the real brother-mfc260c, and the typo in the brother-mfc210c-* packages), I'm quite positive about understanding how the provides/conflicts mechanism works.
Profjim wrote:I think pacman knows to remove the existing package and install the new conflicting package, but only when the install is from a repo, not when one is using -U blahblah.pkg,tar.gz.
I couldn't understand why this should matter from where a package is installed. IMHO this is a totally different layer of abstraction. But I'll make a test repo tomorrow to clear this question.
Concerning your 3-package-suggestion, this wouldn't fit right away because both real packages have to conflict with the original one, because it is ~just~ a split of that package. And maybe there are still some people around using only the LPR driver and not the CUPS wrapper on top of it.
After testing your suggestion, I'll post a feature request and will link it to this thread. AFAICT interpreting a conflicts statement not only against a package with the exact name but also against packages which provide that one is simply a design decision, and not clearly right or wrong. Would it only conflict against a given package, all other packages which provide that one and have files in common would have to be listed in the conflicts array, too.
For the moment I've solved the problem by simply removing the provides-statement, because there is no package explicitly depending on brother-mfc260c, and the probability of it happening will be quite next to zero, but the basic problem still remains, and that's why I wanted to consult the community first before giving the devs extra work.

"There are errors in one or more PL/SQL packages and functions"

Hi all,
first of all - my configuration:
- OWB 10.0.3.0
- one Server HP-UX
- two oracle database instances (plato and platodev)
My problem:
when i try to start "Deployment Manager" and try to connect to the platodev instance i get the RTC-5260 and ORA-01017.
I have no problems to connect to the second instance "plato".
The output of service_doctor is as followed:
===================
SQL> @service_doctor
There are errors in one or more PL/SQL packages and functionsPlatform properties have been loaded correctly
Platform location has been seeded correctly
NLS messages have been loaded correctly
The platform service is available
There is a problem accessing the service startup script from the databaseserver
Here is the detailed error message which contains the name of the startscript file:-
The runtime property 'service_command' either does not exist orcannot be read successfully
oracle.jdbc.driver.OracleSQLException: ORA-00942:
table or view does not exist
Please verify that the disk containing the file is visible to thedatabase server
Please verify that the database server account has access rights on thefile
There is a problem with the repository connection information used tostart the service
Here is the detailed error message which contains the connectioninformation passed to the service:-
Cannot retrieve the repository owner host, port, service-name fromwithin the database server
Please verify that this information is accurate
If this information is correct, then please use the'set_repository_password.sql' script to reset the stored password
PL/SQL procedure successfully completed.
================================0
I did not change the password.
Can anyone help me?
I appreciate your help.
Thank you

Solved!
It was a wrong entry in wb_rt_service_nodes column service_name.

[gambas2] Splitted package and testing repository available!

Similar Messages

Maybe you are looking for