[
http://issues.ops4j.org/jira/browse/PAXCONSTRUCT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_10973
]
Wouter de Vaal commented on PAXCONSTRUCT-61:
--------------------------------------------
Your plan makes sense to me. All the projects own stuff allways gets added to
target/classes, and target/contents is generated when something is added.
The only sideeffect is maybe a clean? I guess not, because all stuff is added
again by an automatic build
> 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
