This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 142048 - Any bugfixes from org.netbeans.modules.j2ee.sun.appsrv aren't deliverable via AUC to users.
Summary: Any bugfixes from org.netbeans.modules.j2ee.sun.appsrv aren't deliverable via...
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9 (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Vince Kraemer
URL:
Keywords:
Depends on:
Blocks: 135838
  Show dependency tree
 
Reported: 2008-07-29 12:22 UTC by pgebauer
Modified: 2008-09-11 14:44 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
messages.log froma vanilla NB 6.1 ML first start after install (54.79 KB, text/plain)
2008-07-31 07:39 UTC, rbalada 		Details
messages.log of NB 6.1 ML first start after test&interim version of patch3 installed (45.84 KB, text/plain)
2008-07-31 07:40 UTC, rbalada 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description pgebauer 2008-07-29 12:22:59 UTC 
In short:
Since the implementation dependency is defined between org.netbeans.modules.j2ee.sun.appsrv81 and
org.netbeans.modules.j2ee.sun.appsrv, any bugfixes from org.netbeans.modules.j2ee.sun.appsrv aren't deliverable via AUC
to users.

In long:
Bugfixes from org.netbeans.modules.j2ee.sun.appsrv (non-visual module) have to be delivered via
org.netbeans.modules.j2ee.sun.appsrv81 (visual module). This is done via both increment of specification version for
j2ee.sun.appsrv and increment of specification version in dependency between j2ee.sun.appsrv and j2ee.sun.appsrv81.
However there is defined also implementation dependency between j2ee.sun.appsrv and j2ee.sun.appsrv81 and so the
specification version change in dependency between j2ee.sun.appsrv and j2ee.sun.appsrv81 doesn't have any effect. Once I
remove implementation dependency between j2ee.sun.appsrv and j2ee.sun.appsrv81, the module j2ee.sun.appsrv81 cannot be
compiled because non-public modules from j2ee.sun.appsrv are used. So there is no way how to deliver bugfixes from
j2ee.sun.appsrv to users.
Comment 1 _ pcw 2008-07-29 17:30:49 UTC 
I suppose we can look a the impl dependency, but why isn't this solved by bumping version numbers on BOTH modules
regardless of where the fix it?  Doesn't that tell AUC to download two new modules, which of course, should have
matching impl dependency?
Comment 2 pgebauer 2008-07-29 22:45:24 UTC 
You propose to work with implementation version analogously as with specification version. Am I right? If so, is a
bugfix that doesn't change any public interface nor class signature sufficient reason for the implementation version
increment? I don't think so but I may be wrong.
Comment 3 _ pcw 2008-07-29 23:51:03 UTC 
I understand that implementation dependencies cause issues for AUC.  What I'm asking is, are those problems
insurmountable, or is there a combination of version bumps we can do here to work past this.

Eliminating the impl dependency as part of this patch delivery strikes me as a much larger more invasive fix that
bumping the version number and delivering an otherwise unchanged module simply because it needed an updated impl
dependency number.
Comment 4 Vince Kraemer 2008-07-30 19:36:59 UTC 
changing the sub to be correcter... none of the modules mentioned in this issue have anything to do with v3...
Comment 5 rbalada 2008-07-31 07:37:13 UTC 
It looks like I was able to resolve that according to wiki page http://wiki.netbeans.org/DevFaqImplementationDependency 

I've incremented org.netbeans.modules.j2ee.sun.appsrv to have implementation version "2", removed specification versions
out of appsrv's manifest and put the spec.version.base into nbproject/project.properties. See changeset
http://hg.netbeans.org/release61_fixes/rev/f4d94d5a8c26 for details. 

I was able to install appsrv and appsrv81 modules in appropriate version from local testing UC.
Comment 6 rbalada 2008-07-31 07:39:38 UTC 
Created attachment 66140 [details]
messages.log froma vanilla NB 6.1 ML first start after install
Comment 7 rbalada 2008-07-31 07:40:46 UTC 
Created attachment 66141 [details]
messages.log of NB 6.1 ML first start after test&interim version of patch3 installed
Comment 8 pgebauer 2008-07-31 12:28:25 UTC 
The fix should be ported to the trunk. Developers, Am I right? Is it suitable solution?
Comment 9 Vince Kraemer 2008-07-31 15:39:15 UTC 
Ported to trunk? I don't know at the moment.  I will need to investigate.  i have p2 issues that are taking up my time
right now, though.  I will let you know Tuesday (unless there is a beta freeze slip)...
Comment 10 pgebauer 2008-09-11 00:15:38 UTC 
The issue still hasn't been fixed in the trunk yet. It may cause obstacles in patch delivery for 6.5 and succeeding
releases.
Comment 11 Vince Kraemer 2008-09-11 00:28:08 UTC 
I think this http://hg.netbeans.org/main?cmd=changeset;node=0d3545f51700 removed the impl dependency in the trunk...
which is a different issue... best I can tell.

Did you reopen this issue based on testing?  can you describe the steps I would need to take to replicate the situation.
Comment 12 pgebauer 2008-09-11 01:05:05 UTC 
I didn't reopened the issue base on testing but the catalog review. I have checked the catalog generated from the last
daily build because I'm checking possible problematic dependencies. I wasn't aware of your changeset 0d3545f51700. It
looked in the catalog like not fixed but I was wrong. The implementation dependency has disappeared also from the
catalog. I'm sorry.

Marking the issue back to FIXED.
Comment 13 Vince Kraemer 2008-09-11 14:44:54 UTC 
no worries