[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] Re: The launcher JAR's class path
- From: "Steven E. Harris" <seh@xxxxxxxxx>
- Date: Fri, 11 May 2007 11:35:29 -0700
- Cancel-lock: sha1:mxMgCQmMPZd56VkKXApAmK5LVH0=
- Delivered-to: email@example.com
- Organization: SEH Labs
- User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (cygwin32)
"Alex Blewitt" <alex.blewitt@xxxxxxxxx> writes:
> However, you can attach it as a standalone fragment to a bundle,
> which means that you've only got one thing to change when you want
> to apply different properties.
When you say "one thing to change", you mean the log4j.properties file
inside my fragment bundle, right? I still have to rebuild the bundle
to push the changes into the framework, unless I've misunderstood your
point here about "standalone" and "one thing". Are you suggesting I
can just point to a log4j.properties file sitting on disk?
> That fragment can even attach directly to the log4j bundle.
I tried that and it worked on the first try.
> You may find that you need to have "Export-Package:
> log4j.properties" if you have it in-bundle in order for log4j to
> find it, but you shouldn't need to do that if attaching to the log4j
> bundle as a fragment.
I didn't export anything, cited my Fragment-Host as "log4j", restarted
the framework with my fragment installed, and that pesky log4j warning
was no more.
I'm not sure setting up the whole Maven module and POM just to jam one
file in there was more worth it than just writing my own manifest, but
at least the packaging process is now repeatable.
Steven E. Harris