onejar does not load log4j.properties from the classpath

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create an artifact com.foo:baz as baz.jar with log4j.properties.
2. Create onejar as baz.onejar.jar.
3. Place another log4j.properties in the working-directory and invoke
baz.onejar.jar with a modified classpath as "java -jar baz.onejar.jar
-classpath .". log4j.properties is loaded from baz.jar instead from the
current directory.

What is the expected output? What do you see instead?
log4j.properties should be loaded from the working directory.

What version of onejar-maven-plugin are you using?
1.4.0

What is the output of "mvn -version" on your machine?
Apache Maven 2.2.0 (r788681; 2009-06-26 14:04:01+0100)
Java version: 1.5.0_17
Java home: C:\Program Files\Java\jdk1.5.0_17\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

Please provide any additional information below.

Original issue reported on code.google.com by balu...@gmail.com on 3 Nov 2009 at 12:26

[GoogleCodeExporter]

Hi!

Thank you for posting your issue here.

I'm sorry to say, this looks like an issue with how One-JAR loads things on
classpath, rather than a problem with how our Onejar Maven Plugin collects your
application together with the One-JAR jar. Anything regarding classloading most
likely originates in the upstream One-JAR project.

Please see their bug tracker, and see if you can find the issue already filed 
there,
or perhaps file it there on your own:
http://sourceforge.net/tracker/?group_id=111153

Marking this issue as "WontFix" here, because we can't do anything about it in 
the
Maven plugin.

Thanks,
Hugo

Original comment by hugo.josefson.old@gmail.com on 17 Nov 2009 at 10:08

• Changed state: WontFix

[GoogleCodeExporter]

Added to the sourceforge tracker: 
https://sourceforge.net/tracker/?func=detail&aid=3013525&group_id=111153&atid=65
8457

Original comment by simontu...@gmail.com on 9 Jun 2010 at 2:21

• Changed state: Accepted

[GoogleCodeExporter]

This issue is fixed in One-Jar 0.97RC6, and should therefore be in the next 
one-jar-maven plugin.  I checked the 1.4.3 release and it is based on RC5, so 
one more update to the plugin is required.   To determine one-jar version, open 
the one-jar-boot-0.97 file inside the one-jar-maven-plugin-1.4.3.jar, and read 
the .version file, which currenetly contains 0.97-rc5-20100528-2308, i.e.  
build RC4, made on May 28, 2010, at 23:08

--simon.

Original comment by simontu...@gmail.com on 14 Jun 2010 at 11:00

[GoogleCodeExporter]

Hi Simon,

You're doing a great job with this!

The reason I included OneJAR 0.97-rc5 in onejar-maven-plugin 1.4.3 is because 
everything about the SourceForge download page showed that it was the 0.97 
release version. When I see a file named for example onejar-0.97.jar, I believe 
it to be the release of 0.97.

I will certainly cut another release of onejar-maven-plugin! I'm worried though 
about the version numbers of OneJAR. Those who have downloaded what the OneJAR 
SourceForge download page said was OneJAR 0.97, will likely believe they have 
the latest version and not re-download when the file's internal contents update 
(if it keeps the same version number in the file name).

From Maven-land we are spoiled with being able to trust that when a certain 
file is named with a certain version number, then the meaning of that version 
number is final. I.e. we can keep that file for every future dependency to that 
version number, and only ever upgrade to another file if we require a different 
version number. It's actually great for stability and non-surprisability when 
you think about it :)

It would mean a lot to me (and others, I think) if you would start a new 
version number for the release of OneJAR, for example 0.97.1 or 0.98, leaving 
0.97 as it is. If more release candidates are in order before final release, I 
would suggest 0.97.1-rc1, 0.97.1-rc2 and so on, leading up to a stable 0.97.1. 
(Alternatively 0.98-rc1, 0.98-rc2... and then finally 0.98).

What do you think, does it make as much sense to you as it does in my head?

Thanks,
Hugo

Original comment by hugo.josefson.old@gmail.com on 15 Jun 2010 at 4:38

[GoogleCodeExporter]

Hi Hugo. Thanks for the input.  When I first released One-Jar 0.95 back in 
2004, after an intense 1-week effort, I did not pay much attention to a 
continuous release process, I just uploaded 0.95 when I was done with it.  
Likewise, the only other release 0.96 was done after a solo effort, and 
published when I was ready.  Now there are many users, and I have switched to 
continuous release, the file-naming certainly needs adjustment to avoid the 
kind of confusion we are seeing here.  I did upload the versions into different 
directories on SourceForge, but once you download it, you don't know what the 
version is, *unless* you look at the .version inside the Jar file, or pass in 
the "--one-jar-version" argument at runtime.

Fortunately, since the "default" download still points at 0.96, only 
bleeding-edgers will be seeing the 0.97 files.  

This will impact my test-suites, which are keyed to the "0.97" string in the 
filenames in 7 locations.  Once I introduce -rcX into the filenames I will have 
to abstract the tests to key off the .version file (which is written by the Ant 
build script), so that the 0.97 string is hardcoded only in one place: the 
build.xml file.

I did plan to revisit this when I hit 1.0, since one-jar-boot-100.jar doesn't 
look anywhere near as nice as one-jar-boot-1.0.0.jar.  

For now I will switch to the following convention: 0.97-rc7 will be the next 
build (and should be the last), then 0.98 will become 0.9.8 with release 
candidate 1 being 0.9.8-rc1 and so on.

I don't plan to let the product sit for as long this time, since activity seems 
to be picking up and I'm most encouraged by your effort to make it available to 
Maven users.  

Thanks!

Simon.

Original comment by simontu...@gmail.com on 15 Jun 2010 at 5:28

[GoogleCodeExporter]

Hi!

Yeah, it feels good when you see your project being used more and more. I like 
that feeling too :)

It's also great that you see the potential in having a rigid filename version 
structure! However, the proposed change from 0.98 to 0.9.8 would actually mean 
that automated tools such as Maven, which look at the version numbers, would 
think 0.9.8 is *much* older than 0.97, because 9 < 97. Since you have started 
using 0.96, 0.97... I would recommend continuing with that. There is also 
nothing wrong with 0.99, 0.100, 0.101 and so on; Look at Hudson for example :) 
You can still release 1.0.0 when you feel the stability and functionality is 
done enough.

Just to be clear, should I take the 0.97-rc7 when it comes out? (Please ping me 
then)

Again, thanks for all your good work. Keep it up!

/Hugo

Original comment by hugo.josefson.old@gmail.com on 15 Jun 2010 at 5:51

[GoogleCodeExporter]

Hi Hugo:  good point about the numbering convention, and Maven, from which I 
can only conclude that nobody is using One-Jar with Maven outside of your 
plugin, which conveniently hides the one-jar release file inside it. 
Fortunately, since one-jar-boot isn't really a library you would link against I 
think we're safe.

I'll hold-off any renaming changes if that's OK with you, since the code is 
pretty stable now and I'm just looking to get it released.  At this point, I 
have three outstanding issues, two of which look outside the scope of 0.97, and 
one of which I'm investigating tonight. Which means I should have an 0.97-rc7 
by tomorrow for you to test, and if no issues arise then I'll push the final 
0.97 live next week (one week to stabilize, and for anyone to complain, should 
be enough).

The next release will probably be 0.98 (when I will switch over to a better 
naming convention with -rcNN in the name, to help us all out).  

Then probably 1.0.0.  As to my goal for 1.0.0, I have found out a lot over time 
about how to improve the code, and a major refactoring and code collapsation 
(not a real word) is in order.  I will probably remove some things that (to my 
knowledge) nobody has ever used, in order to shrink the code down and clean it 
up.  So I will make the goal of 1.0.0 to refactor and collapse, but not change 
the important semantics of One-Jar, so that you shouldn't be affected.  

I'll ping you tomorrow.

Simon.

Original comment by simontu...@gmail.com on 15 Jun 2010 at 6:21

[GoogleCodeExporter]

Yes, you're correct that version numbering of One-JAR is just a convenience and 
clarity thing. The Maven plugin can be made to work any way you name the 
release jars.

I don't have any specific ways of testing your releases, so I will rather 
simply release a new version of the plugin. Then those who use One-JAR via the 
Maven plugin can try it out. Whenever you release new versions/release 
candidates, I can release new point releases.

Thanks,
Hugo

Original comment by hugo.josefson.old@gmail.com on 15 Jun 2010 at 6:38

[GoogleCodeExporter]

Hi Hugo:

I have just uploaded RC7 to SourceForge, you can download it here: 

https://sourceforge.net/projects/one-jar/files/one-jar/one-jar-0.97-RC7

This should be the final RC, unless something crops up.  I do have some minor 
work to do on a tool called one-jar-appgen, but that should not affect the 
one-jar-boot code that your maven plugin relies on.

I'll monitor this forum for feedback.  

Thanks!

--simon.

Original comment by simontu...@gmail.com on 16 Jun 2010 at 3:33

[GoogleCodeExporter]

Hi, I actually ran into this problem today, and was wondering when you would be 
able to cut a new version of the maven plugin. If you don't have time to do it 
for a while, I can just roll my own...

A big thank you to both Simon and Hugo. Your projects are great.

Original comment by ben.lamo...@gmail.com on 22 Jun 2010 at 9:46

[GoogleCodeExporter]

Actually, you may want to hold off making a new version of the plugin. I went 
and added the newest version of onejar and ccompiled it myself and now I'm 
getting NullPointerExceptions. Going to go and file a bug over at the one-jar 
site.

Original comment by ben.lamo...@gmail.com on 22 Jun 2010 at 10:53

[GoogleCodeExporter]

Hi Ben:  I'll watch out for your bug report, One-JAR is at RC6, in 
stabilization, so I want to fix this if I can.  I can reproduce a Maven build 
problem if it's easier to submit it that way, otherwise if you can fake up a 
One-JAR Ant project that would be great.  

Simon.

Original comment by simontu...@gmail.com on 22 Jun 2010 at 11:13

[GoogleCodeExporter]

Hi Hugo,

Simon has fixed the issues I was seeing and released RC8. I ended up rolling my 
own version of your plugin, so I have no pressing need to have a new version 
cut, but as soon as you do release a new version I'll switch over to the 
official plugin.

Original comment by ben.lamo...@gmail.com on 23 Jun 2010 at 5:23

[GoogleCodeExporter]

Until there's a new release of the plugin that has the latest version that you 
need, try this: the newest snapshot versions allow to specify a custom one-jar 
file (of any version).

Example: 
<localOneJarTemplate>bin/onejar/onejar-boot-97RC.jar</localOneJarTemplate>

Original comment by bwijsmul...@gmail.com on 22 Jan 2012 at 11:02