Hi Thorsten, now I am back - but my problem remained. This is my problem, ist is very simple:
There are some classes, packaged in myApp.jar. Then there are some dependencies, e.g. only one: dependOn.jar I can do this: Have a foulder with myApp.bat, myApp.jar and dependOn.jar. The manifest.mf in myApp contains "classpath: dependOn.jar". This works! But I not only one dependend jar. There will be many, all defined in my pom as dependency. I would like to have not a whole directory structure on my target system to be maintained but only one jar and one bat-file. If I put the dependOn.jar in my myApp.jar, then it isnt further reachable by my classloader. See: http://one-jar.sourceforge.net/ So I have to unpck and flatten all dependend jar-files and introduce them into my MyApp.jar as a flat directory structure. But this makes problems, esp. the COM-/com- Problem, but maybe others too. My hope was, that maven-assembly-plugin could help in any way - but I didnt find that way. Perhaps it could be a futher task of that plugin, to introduce some custom code controlling the class loader like suggested in the project "one-jar". There are some further things I don't understand with the assembly-plugin: I have severel dependencies: commons..., log4j, poi, struts ... They have the same dependency-level, but struts is expanded in a flat directory even if I say unpck false. The others are not! Why? Why is this Java-stuff like rt.jar, jsse.jar and all stuff from JRE System library (in eclipse) packaged, when I say unpack true? It is NOT mentioned in any dependency, it is implicite! May be it isn't worth to spend more time for this. I will proceed as I have done before and copy all stuff I ned in a seperate folder called ./lib/ and have myApp.jar with no futher libraries but mine. Many thanks for your hints. I think, I will do now just that you suggested! Cheers Holger -----Original Message----- From: Thorsten Heit [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 9:33 AM To: Maven Users List Subject: Re: maven-assembly-plugin converts com.xxx - packages to COM.xxx - packages Hi Holger, > Maven should do just that for me, and it would work, if it woudnt > mix all > the Java stuff from the JRE into this archive (rt.jar, sunrasign.jar, > jsse.jar, jce.jar, ...)! This is in the JRE and I don't need it in > my jar. I don't fully understand why you want to pack everything into one jar and not use Java's ability to let a jar file depend on others via the "Class-Path" section in its manifest file. This would make things a bit easier, and additionally you can avoid the problems of adding all the JRE stuff to your archive... > Thre is some further stuff, I don't need - the struts- and j2ee > environment, > but I think, I can exclude them. If they are added, then there is a dependency to these packages somewhere in a POM you're using... > Any Idea? I think it is a bug, to mix COM- and com- directories, > they should > be apart. But perhaps this is a problem of java.util.jar On Windows, "COM.xxx" == "com.xxx" when it comes to opening or accessing files/directories, but on Unix machines not. AFAIK IBM also used "COM." in some JDBC driver jars for DB2 8.x so there would be similar problems if you'd use these drivers... I still suggest you avoid packaging everything (including JRE stuff) into one huge jar file ;-) HTH Thorsten ****************************** Disclaimer: Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der beabsichtigte Empfänger sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender telefonisch oder per E-Mail und loeschen Sie diese E-Mail aus Ihrem System. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Wir haften nicht für die Unversehrtheit von E-Mails, nachdem sie unseren Einflussbereich verlassen haben. Disclaimer: 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 by call or e-mail and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We are not responsible for the integrity of e-mails after they have left our sphere of control. ****************************** sds business services GmbH Stinnes-Platz 1 45472 Muelheim an der Ruhr Amtsgericht Duisburg, HRB 18564 Geschaeftsfuehrer: Albrecht Held Bernhard Wildt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
