[sip-comm-dev] skinresources.jar as a resource (or not)


#1

Hey all,

We just had a chat with Adam about the best way to handle
skinresources.jar. This jar is basically a skin template. It contains
the class part of a skin. We use it so that users would be able to
create skins by only creating a zip file with images and property/xml
files. SC then converts these zips to bundle jars by attaching the zip
content to that of skinresources.jar.

Now, the question is: how should we be handling this jar and where
should we be storing it.

We are currently building and deploying it in sc-bundles. The problem is
that in order to access it, we are currently using the "user.dir"
property (working directory) and the "sc-bundles" name in the code, and
we'd better not.

Ideally, we should be storing files that we need to access during
runtime in our resources directory. However the skinresources.jar does
not quite fit there either since it needs to be compiled, built, and
most importantly cleaned. It represents dynamic content and we don't
store such content in the "resources" dir.

After discussing this Yana, Lubo, and Adam, the following plan has emerged:

1. We are going to try and see whether we can somehow access the
sc-bundles directory through felix, without explicitly naming it

(I doubt this because we have never really defined the name anywhere
other than the individual bundle locations)

2. We get the bundle to actually start, then try to access it via the
bundle context, and then discover the jar location from there

(It is important to note that the bundle should only be installed and
not started so that we don't confuse it with an active skin. Adam this
means you would have to place it in an auto.install clause rather than
an auto.start)

3. We crate a new directory in resources that we deem as dynamic and
cleanable and we generate the jar in there. We also update build.xml to
purge that directory when "clean: is called.

(In this case we are running the risk of people accidentally committing
the jar on SVN)

I actually have a 4. now but I'll put it in a reply to this mail since
it wasn't dicsussed during my chat with Adam.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey again,

На 07.09.10 12:54, Emil Ivov написа:

3. We crate a new directory in resources that we deem as dynamic and
cleanable and we generate the jar in there. We also update build.xml to
purge that directory when "clean: is called.

(In this case we are running the risk of people accidentally committing
the jar on SVN)

I actually have a 4. now but I'll put it in a reply to this mail since
it wasn't dicsussed during my chat with Adam.

So it just dawned on me while writing 3, that

4. in order to have something in defaultresources.jar we don't need to
have it in sip-communicator/resources. It simply needs to go in what our
build.xml calls ${resources} and that actually corresponds to
sip-communicator/classes/resources.

This way we won't need to be taking care of any new cleaning mechanisms
and we won't be filling our resources dir with dynamic, buildable
content (although we would need to add a "skins" entry in the "jar" task
of the "bundle-resources-defaultpack" target).

If you guys don't see any issues with this, then Adam I guess you could
skip 1, 2, and 3 and start with this one.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

Hey again,

На 07.09.10 12:54, Emil Ivov написа:

3. We crate a new directory in resources that we deem as dynamic and
cleanable and we generate the jar in there. We also update build.xml to
purge that directory when "clean: is called.

(In this case we are running the risk of people accidentally committing
the jar on SVN)

I actually have a 4. now but I'll put it in a reply to this mail since
it wasn't dicsussed during my chat with Adam.

So it just dawned on me while writing 3, that

4. in order to have something in defaultresources.jar we don't need to
have it in sip-communicator/resources. It simply needs to go in what our
build.xml calls ${resources} and that actually corresponds to
sip-communicator/classes/resources.

Did you mean skinresources.jar, or you're proposing to put the SkinResourcePack in the defaultresources.jar ?

Cheers,
Yana

···

On Sep 7, 2010, at 12:04 PM, Emil Ivov wrote:

This way we won't need to be taking care of any new cleaning mechanisms
and we won't be filling our resources dir with dynamic, buildable
content (although we would need to add a "skins" entry in the "jar" task
of the "bundle-resources-defaultpack" target).

If you guys don't see any issues with this, then Adam I guess you could
skip 1, 2, and 3 and start with this one.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Yana,

На 07.09.10 13:13, Yana Stamcheva написа:

4. in order to have something in defaultresources.jar we don't need
to have it in sip-communicator/resources. It simply needs to go in
what our build.xml calls ${resources} and that actually corresponds
to sip-communicator/classes/resources.

Did you mean skinresources.jar, or you're proposing to put the
SkinResourcePack in the defaultresources.jar ?

I believe I did mean skinresources.jar - the template jar that we access
from the code.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Emil, Adam,

Hey Yana,

На 07.09.10 13:13, Yana Stamcheva написа:

4. in order to have something in defaultresources.jar we don't need
to have it in sip-communicator/resources. It simply needs to go in
what our build.xml calls ${resources} and that actually corresponds
to sip-communicator/classes/resources.

Did you mean skinresources.jar, or you're proposing to put the
SkinResourcePack in the defaultresources.jar ?

I believe I did mean skinresources.jar - the template jar that we access
from the code.

Ok, I like 4:) I agree that it seems to be the best solution.

Cheers,
Yana

···

On Sep 7, 2010, at 12:24 PM, Emil Ivov wrote:

Emil


#6

Hey all,

Emil, Adam,

Hey Yana,

�� 07.09.10 13:13, Yana Stamcheva ������:
    

4. in order to have something in defaultresources.jar we don't need
to have it in sip-communicator/resources. It simply needs to go in
what our build.xml calls ${resources} and that actually corresponds
to sip-communicator/classes/resources.
        

Did you mean skinresources.jar, or you're proposing to put the
SkinResourcePack in the defaultresources.jar ?
      

I believe I did mean skinresources.jar - the template jar that we access
from the code.
    

Ok, I like 4:) I agree that it seems to be the best solution.

Cheers,
Yana

So I'll skip 1,2 and 3 and will proceed with the 4.

Cheers,
Adam

···

On 09/07/2010 12:33 PM, Yana Stamcheva wrote:

On Sep 7, 2010, at 12:24 PM, Emil Ivov wrote:

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Yana,
could you please merge the latest patch with the trunk so i can proceed
with the patching ;). Thanks.

Cheers,
Adam

···

On 09/07/2010 12:33 PM, Yana Stamcheva wrote:

Emil, Adam,

On Sep 7, 2010, at 12:24 PM, Emil Ivov wrote:

Hey Yana,

�� 07.09.10 13:13, Yana Stamcheva ������:
    

4. in order to have something in defaultresources.jar we don't need
to have it in sip-communicator/resources. It simply needs to go in
what our build.xml calls ${resources} and that actually corresponds
to sip-communicator/classes/resources.
        

Did you mean skinresources.jar, or you're proposing to put the
SkinResourcePack in the defaultresources.jar ?
      

I believe I did mean skinresources.jar - the template jar that we access
from the code.
    

Ok, I like 4:) I agree that it seems to be the best solution.

Cheers,
Yana
  

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Adam,

Hi Yana,
could you please merge the latest patch with the trunk so i can proceed
with the patching ;). Thanks.

Yep, I'm applying it right now and it'll be there in minutes.

Cheers,
Yana

···

On Sep 7, 2010, at 12:46 PM, Adam Netocny wrote:

Cheers,
Adam

On 09/07/2010 12:33 PM, Yana Stamcheva wrote:

Emil, Adam,

On Sep 7, 2010, at 12:24 PM, Emil Ivov wrote:

Hey Yana,

На 07.09.10 13:13, Yana Stamcheva написа:

4. in order to have something in defaultresources.jar we don't need
to have it in sip-communicator/resources. It simply needs to go in
what our build.xml calls ${resources} and that actually corresponds
to sip-communicator/classes/resources.

Did you mean skinresources.jar, or you're proposing to put the
SkinResourcePack in the defaultresources.jar ?

I believe I did mean skinresources.jar - the template jar that we access
from the code.

Ok, I like 4:) I agree that it seems to be the best solution.

Cheers,
Yana

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net