pax:eclipse - target/contents classpath entry can cause strange issues with
Spring-DM resource loading
------------------------------------------------------------------------------------------------------
Key: PAXCONSTRUCT-61
URL: http://issues.ops4j.org/jira/browse/PAXCONSTRUCT-61
Project: Pax Construct
Issue Type: Bug
Components: maven-pax-plugin
Affects Versions: 0.6.2
Reporter: Wouter de Vaal
Assignee: Stuart McCulloch
Fix For: 0.6.3
On Dec 11, 2007 3:31 AM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
>
> On 11/12/2007, Wouter de Vaal <[EMAIL PROTECTED]> wrote:
>
>
> > Hi,
> >
> > When I upgraded to the latest pax construct plugin, I get an extra manifest
> > header for the eclipse manifest:
> > Bundle-ClassPath: .,target/contents
>
>
> yes - this is expected, because when using Bnd you may have classes inside
> your bundle
> that aren't on your sourcepath (for example classes or resources inlined from
> other jars)
>
> therefore, the modified Eclipse mojo unpacks the final bundle and adds
> target/contents
> to the Eclipse classpath (_after_ the source entries) so that the
> "non-source" classes are
> available - it can't use target/classes, because this will be wiped by
> Eclipse when doing
> a clean build, so we use target/contents - and it's easier to unpack
> everything than try
> to work out which bits are related to local source files, and which aren't...
Ok now I have an idea why this is done. I allways told my collegues
not to call project->clean, but I guess this is now ok to do, right?
>
>
>
> > This is quite annoying, as the class files are also copied there during a
> > maven build but not when I edit an save a file within eclipse. Now there
> > are two versions on the classpath when running equinox from within eclipse,
> > which leads to freaky errors.
>
>
> what sort of errors? when you edit and save a file in Eclipse it should do
> an incremental
> build to target/classes, which is before target/contents on the Eclipse build
> path - so any
> modified classes should always appear _before_ their previous unpacked
> version.
>
> can you send instructions on how to recreate these errors, or at least
> provide a bit more
> detail - as it's better to fix the cause, not the symptom... just turning the
> feature off isn't
> an option for some users that need this unpacking
Ok I've got more info now. We don't have any issues with classes. The
issues lies in
the use of a spring context .xml file. We have put this on the
classpath using the Spring-Context: classpath:applicationContext.xml
header. The file itself is in src/main/resources and gets updated to
target/classes on safe, just like te rest of the classes, so nothing
strange there.
However when I foobar something in the beans definition (like changing
a bean id without updating the references) and I call update
<bundlenr> from the osgi console, this issue isn't picked up. When I
remove the target/contents part from the Bundle-ClassPath header and
update, spring shows an error. When I put the classpath entry back
again and update, the error is gone.
Is this enough information for you to go on, do you use spring yourself?
- Hide quoted text -
Wouter
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
