Re: [skalli-dev] How many launches to you want to have?

["Schneider, Juergen" <ju.schneider@xxxxxxx>]

Hi Jochen,

You pointed out the three options totally right. I expect only one method in the sources where the storage folder is determined:

PersistenceServiceXStream.initializeStorage()

The workdir is the only thing that can be configured in skalli.properties at the moment.

We have introduced option c) to have a solution for deploying skalli including our extensions on a central system without reconfiguring the system afterwards to have it up and running immediately. Currently we need to configure the workdir only, but I expect that there will be more configuration options in future. Merging Skalli bundles together with our bundles (including the configuration fragment) are really straightforward.

Option a) and b) address the local developer scenario (at least in our case) and if there is a OSGi standard, I would vote to support it, nevertheless I'm not familiar with this standard in detail and on the first look it seems to be used for eclipse plug-in developers.

However, I would like to mention here another standard for configuration in the world of OSGi, the OSGi configuration admin service<http://www.osgilook.com/osgi-configuration-admin-service/>.

My feeling is that configuration becomes more complicated since we have to support more scenarios, so I would like to discuss the configuration topic as a whole instead of discussing the workdir only.

Any comments? As you see, I don't have THE answer, only questions ;)

Cheers,
  Juergen


From: Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx<mailto:jo.hiller@xxxxxxxxxxxxxx>>
Reply-To: Skalli project developer mailing list <skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx>>
Date: Fri, 13 May 2011 10:47:58 +0200
To: Skalli project developer mailing list <skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx>>
Subject: Re: [skalli-dev] How many launches to you want to have?

Hi Juergen,

thanks for your explanation.

So, for configuring the storage there are 3 options:

a) use current working directory (as used in skalli.launch)

b) specifiy a Java system property -Dworkdir=....
See ConfigurationComponent.getWorkdirFile()

c) specify a property "workdir=..." in skalli.properties
This file will be lookup by bundle o.e.s.common, so customizations have to be a fragment to this bundle


I had a short chat with Simon whether Skall should also support the OSGi standard mechanism, to use the osgi.instance.area as workdir. The workdir is more or less the concept of a workspace within Eclipse IDE, grouping all files for one setup/configuration. This could be an addon/replacement of option b)

See http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html for OSGi standard options.

What do you mean?


What is the best way to understand about the customizations which can be done currently?
Class PersistenceServiceXStream?

Thanks, Jochen


On Fri, May 13, 2011 at 10:25 AM, Schneider, Juergen <ju.schneider@xxxxxxx<mailto:ju.schneider@xxxxxxx>> wrote:
Hi Jochen,

Just to add some comments on configuration of the storage folder: There is a mechanism to get that storage folder path from a property file that has to be in the class path root. Doing so we can customize the storage folder by adding a bundle fragment including that property file. For us it's much easier to implement a separate bundle (fragment) that is deployed together with the  skalli bundles instead of touching particular files that came with skalli sources (this is something we call a 'build hack'). In general, as you mentioned your 'telekom customization', it is obvious that we have a 'sap customization' (e.g. the bundle fragment including the property file mentioned above). I think this could be the way to go for all customization that needs to be adapted by different organizations.

The only thing that is missing at the moment is a description how to write such a bundle fragment, I will adapt the contributor guide asap.

Cheers,
 Juergen

From: Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx<mailto:jo.hiller@xxxxxxxxxxxxxx><mailto:jo.hiller@xxxxxxxxxxxxxx<mailto:jo.hiller@xxxxxxxxxxxxxx>>>
Reply-To: Skalli project developer mailing list <skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx><mailto:skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx>>>
Date: Thu, 12 May 2011 20:39:20 +0200
To: Skalli project developer mailing list <skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx><mailto:skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx>>>
Subject: Re: [skalli-dev] How many launches to you want to have?

Hi Britta,

On Thu, May 12, 2011 at 5:29 PM, Varwig, Britta <britta.varwig@xxxxxxx<mailto:britta.varwig@xxxxxxx><mailto:britta.varwig@xxxxxxx<mailto:britta.varwig@xxxxxxx>>> wrote:
Hello,
on http://wiki.eclipse.org/Skalli/Contributor_Guide#Run_Skalli_from_IDE a patch with an skalli-jetty.launch is available (has not reached origin/master by now).

Additionally a skalli.lauch is available in project org.eclipse.skalli.target.
What was the reason to have both?

added my comment to https://bugs.eclipse.org/bugs/show_bug.cgi?id=343826

One launch config is fine, only property has to be fixed to OSGi standard. Reopened the bug.

Additionally I would like to provide a workdir with some  testdata. (some example projects and users fitting to the jetty-users)
Benefit for Skalli beginners:  they fast can get a feeling of a working and filled skalli.

Thats a good idea.

 I would like to have a suitable launch file for that as well, or can I “reuse” the current available one and just add the testdata to the current workdir?

For a quick startup, it is an good idea to have a non-empty storage to play around with, especially for simple demoing purposes. I would reuse the o.e.s.target/workdir as default directory.

For other needs, developers can adapt or clone the launch config for their needs (like I am doing for my Telekom customization).

Regards Britta

Bye, Jochen

_______________________________________________
skalli-dev mailing list
skalli-dev@xxxxxxxxxxx<mailto:skalli-dev@xxxxxxxxxxx>
http://dev.eclipse.org/mailman/listinfo/skalli-dev