Hi Henrik,

Can you confirm which mojo of the webstart plugin you are using, or want 
to continue using? It depends on how you plan on deploying the JNLP 
bundle, e.g. servlet container vs webserver. I'm afraid I can only give 
advice on the JnlpDownloadServletMojo, as that's the only one I use.


Cheers,
Kevin







"Henrik Dohlmann" <[EMAIL PROTECTED]> 
22/10/2007 10:24
Please respond to
[email protected]


To
<[email protected]>
cc

Subject
RE: [mojo-user] Use webstart plugin with proguard






Okay, I have now experimented with obfuscating all the needed jars first, 
dumping them into target and running jnlp-inline after. Unfortunately, 
that does not work. The webstart plugin ignores all the obfuscated jars 
and just use the non-obfuscated ones from the repository instead? What am 
I doing wrong here?
 
Then I tried to put all the obfuscated jars in a subdirectory of target 
and telling the webstart-plugin to use this subdir as workDirectory. This 
sort-of-worked but not quite. Now, webstart-plugin packages all my 
obfuscated jars, together with the unobfuscated dependencies, but it does 
not perform the pack-200 nor the jarsigning on the obfuscated jars. Yikes, 
so close but still no joy?
 
So, how do I convince the webstart-plugin to perform the pack200 and 
jarsign on my freshly proguarded jars as well as on the pulled in 
dependencies?
 
The other option, obfuscating the jars separately and storing them with a 
classifier alongside the unobfuscated jar, only works partially. I need to 
specifically use a command-line ?-Dpg=classifier? for this to work. I 
tried to create profiles, where this classifier is defined, like this:
  <profiles>
    <profile>
      <id>dev</id>
      <activation><activeByDefault>true</activeByDefault></activation>
      <properties>
        <pg></pg>
      </properties>
    </profile>
    <profile>
      <id>rel</id>
      <properties>
        <pg>pg</pg>
      </properties>
    </profile>
  </profiles>
Unfortunately, when specifying ?-Prel? the webstart-plugin still manages 
to pull in some of the unobfuscated jars. This might be a separate error 
compared to MWEBSTART-54.
 
Regards,
/Henrik
 
From: Kevin Stembridge [mailto:[EMAIL PROTECTED] 
Sent: 19. oktober 2007 15:49


I'm sure you could obfuscate all your jars if you want to. From the 
webstart plugin's perspective it makes no difference whether the artifacts 
are obfuscated or not, it just assembles the artifacts that you tell it 
to, along with transitive dependencies. Although I still need to sort out 
the system and test scope issue. I've raised an issue for that if you want 
to keep an eye on it. 

http://jira.codehaus.org/browse/MWEBSTART-54 


With regards to when and how to obfuscate the jars, my approach would be 
to use proguard in each module. Also, you might find it useful to add your 
proguard and webstart plugin to a profile so that it only runs, for 
example, when you are ready to do a build and deploy it via webstart. I'm 
guessing that during development you will be running the unobfuscated code 
and only deploy the obfuscated code for system testing. 


Re: provided scope. In your client project I would declare the core module 
to be a provided dependency. If I'm correct in assuming that Configurator 
is your maven project that creates the JNLP bundle, then this module 
doesn't have a dependency on either client or core, although you may need 
to declare it as such to ensure the correct build order. Unlike the other 
mojos in the webstart plugin, the JnlpDownloadServletMojo ignores the 
dependencies of the project in which it is used, instead it has a 
configuration section that defines the artifacts to be bundled. 


---

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional 
EU corporate and regulatory disclosures.

Reply via email to