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 24143 - support building openide.nbm and/or core.nbm
Summary: support building openide.nbm and/or core.nbm
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
: 16069 (view as bug list)
Depends on: 24361
Blocks: 22922
  Show dependency tree
Reported: 2002-05-28 16:00 UTC by rbalada
Modified: 2008-12-22 22:09 UTC (History)
5 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

I seem to have it. Jesse, I am composing the org-openide.nbm in temporary directory openide/fake and copying there a openide/netbeans core/netbeans and core/*/netbeans content, is this a possible solution or do you want to change something? If this is ge (5.88 KB, patch)
2002-05-31 16:10 UTC, Jaroslav Tulach
Details | Diff
Possible patch from current CVS sources (16.36 KB, patch)
2002-06-03 22:13 UTC, Jesse Glick
Details | Diff
Different patch making separate core.nbm, openide.nbm, and core-*.nbm (23.27 KB, patch)
2002-06-03 23:36 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rbalada 2002-05-28 16:00:07 UTC
During implementation of issue 22922 I discovered
old known problem, that NetBeans don't support
update of OpenIDE and Core using .nbm files.


or see discussion in thread
Comment 1 Jesse Glick 2002-05-28 16:20:31 UTC
IMHO the basic issue here is a lack of feature support in the
autoupdate module.
Comment 2 _ mihmax 2002-05-29 22:11:23 UTC
Why don't make a hack: create an empty module thecore.nbm, 
which will include:
- lib/core.jar, 
- lib/core-*.jar's, 
- lib/openide.jar
- modules/thecore.jar - small and absolutely empty, non-
functional module with only one bundle inside and with a 
module manifest
Comment 3 Jesse Glick 2002-05-30 02:25:05 UTC
That will mostly work. It will not work to update thecore.nbm when a
module declares that it needs a newer OpenIDE version. However you
could maybe hack around that by changing <makenbm> to replace

OpenIDE-Module-IDE-Dependencies: IDE/1 > 2.34


OpenIDE-Module-Module-Dependencies: thecore/1 > 2.34
Comment 4 Jaroslav Tulach 2002-05-30 08:29:06 UTC
Ok, so I can try to do following:

I'll add the build of fake module to the core/build.xml nbm target. It
will create the nbm with the structure Maxym suggested. There will be
no openide/build.xml nbm target.


Is the name "thecore" the right one we should use? 
There is a plan to separate openide to pieces and to slowly remove
some of them - the current suggestion is that we will introduce
thecore2, thecore3 modules. Is this the right way to proceed? Should
not I call the module thecore-minus5 ;-?
Comment 5 _ mihmax 2002-05-30 09:19:03 UTC
> -- from Jesse --
> However you
> could maybe hack around that by changing <makenbm> to replace
> OpenIDE-Module-IDE-Dependencies: IDE/1 > 2.34
> with
> OpenIDE-Module-Module-Dependencies: thecore/1 > 2.34

not replace, but add along, I suppose,
because modules must be dependent on the version of the core
Comment 6 Jesse Glick 2002-05-30 17:46:04 UTC
To Maxym: no, really replace. But *only* in the Info/info.xml file in
the NBM, *not* in the actual module manifest. E.g. you are currently
running OpenIDE v. 1.23, and thecore (or whatever) 1.23. You see a new
module that says it requires thecore 1.24. AU will then update thecore
if you request the new module. You cannot leave the OpenIDE dependency
in the info.xml file or AU will just say the new module cannot be run
on your current installation at all. But if it thinks that thecore is
a regular module, it should happily download both, unpack, and restart
NB, at which point the NB module system will verify that the
dependencies really work (it does not trust AU to do this).

To Yarda: I guess I would actually use "org.openide" as the module
name. If we do later split up openide into pieces, the new pieces will
presumably be real modules, so we don't have to worry about them.
"org.openide" will continue to mean the remaining monolithic Open
APIs. We can do something in AU similar to what the module system
does: if you e.g. split off the Execution API, you can change
<makenbm> (or AU client??) to make old modules (with low IDE/1
dependencies) automatically depend on the new autoload, whereas newer
modules (with high IDE/1 dependencies) can choose whether or not to
depend on it. The physical API would be removed from the startup
classpath of course. Does that work?
Comment 7 Jaroslav Tulach 2002-05-31 16:10:15 UTC
Created attachment 6033 [details]
I seem to have it. Jesse, I am composing the org-openide.nbm in temporary directory openide/fake and copying there a openide/netbeans core/netbeans and core/*/netbeans content, is this a possible solution or do you want to change something? If this is ge
Comment 8 Jesse Glick 2002-05-31 16:47:46 UTC
That sounds basically right to me.

1. <license> will need to include licenses for all extra binaries
included in the core. Perhaps Ruda can help here by patching the build
script after it is basically working.

2. Petr Hr. - it is ugly that all the core submodules are *still* in
lib/. They do not need to be here AFAIK. They should be in
modules/eager/ (later modules/autoload/ for some like compiler and
execution that may not always be needed). And they should have their
own NBMs just like any module. Note that core/javahelp is already
treated as a regular module.

3. Consider the fact that unpacking org-openide.nbm might clobber file
permissions of e.g. on Unix. Ales, do you know if this is a
problem, and does AU support extracting with permissions?

4. You probably cannot put the localizing bundle for the module in the
org.openide package. It might not be found (since org.openide is
available in app classpath). I would recommend having a separate mini
source tree containing just e.g.

If you would like help with 1 & 4 especially and maybe 2 & 3, feel
free to assign to me; I can work on it and commit a revised version of
the patch. Your choice.

BTW avoid such long comments in attachment descriptions, they are not
line-wrapped in IZ's display...
Comment 9 Jaroslav Tulach 2002-06-01 09:31:07 UTC
nbm target is in CVS. I've implemented just the #4 - not using
org/openide/ for description of the module bundles.
Jesse reassigning to you to take care of anything else you think
should be done.

/cvs/openide/build.xml,v  <--  build.xml
new revision: 1.93; previous revision: 1.92

RCS file: /cvs/openide/,v
Checking in;
/cvs/openide/,v  <--
initial revision: 1.1
RCS file: /cvs/openide/,v
Checking in;
/cvs/openide/,v  <--
initial revision: 1.1
Comment 10 Jesse Glick 2002-06-02 21:16:23 UTC
I guess should be in a package, not
top-level... also perhaps org-openide.jar should be "eager" to make
sure users cannot turn it off. I will check on it. Thanks for initial
Comment 11 Jesse Glick 2002-06-03 19:13:47 UTC
I see one problem: in order to let the user actually update this NBM
from a real build, the fake module needs to be included in a regular
build, so there is something to update from. I.e. if the fake module
is not in the regular build, any user going to the update center will
see it as a potential download, and any module depending on it will
cause the whole NBM to be retrieved - even if the user in fact already
has the correct version of core!

So can this this fake module be included in the standard module list
as generated by openide/build.xml:netbeans, and in the standard
Comment 12 Jesse Glick 2002-06-03 22:13:20 UTC
Created attachment 6055 [details]
Possible patch from current CVS sources
Comment 13 Jesse Glick 2002-06-03 22:17:17 UTC
The attached patch makes openide.jar into a real module with name
org.openide/1. openide-core.nbm contains all core and openide files.
Auto Update is modified to treat API dependencies as actually being a
dependency on org.openide/1, so that openide-core.nbm can be
downloaded if needed.

I am going to explore whether it is in fact possible to make separate
openide.nbm and core.nbm and core-*.nbm files, divided in the natural
way, and have AU actually understand it. That would be cleaner than
this patch, I think. It depends on what our policy is for updating
core & openide separately. I hope it is OK to update only openide, but
not OK to update only core.
Comment 14 Jesse Glick 2002-06-03 22:19:05 UTC
*** Issue 16069 has been marked as a duplicate of this issue. ***
Comment 15 Jesse Glick 2002-06-03 22:33:34 UTC
Above patch also needs to comment out <genlist> task in netbeans
targets of core/*/build.xml.
Comment 16 Jesse Glick 2002-06-03 23:36:19 UTC
Created attachment 6057 [details]
Different patch making separate core.nbm, openide.nbm, and core-*.nbm
Comment 17 Jesse Glick 2002-06-04 00:35:40 UTC
Fixed with the second patch. It really seems to work on Linux at
least. On Windows I would assume issue #24361 would be a problem.

I tried creating fake updates to core.nbm, openide.nbm, and text.nbm,
where the new core and text both depended on the new openide. The AU
wizard with the patch correctly forced you to get openide.nbm if you
chose either core.nbm or text.nbm or both.


(1) This impl requires that openide be kept compatible even for "inner
APIs", i.e. things which can only be implemented by core. Example:
adding a new method to is incompatible
even though only core can be affected. If the user updates the new
openide.nbm, he/she will have to update core.nbm too (AU will not
force it), or errors may result.

(2) OpenIDE-Module: org.openide/1 is in fact used in openide.jar and
it works for AU. You cannot manually add a new lib/*.jar module using
the ModuleNode GUI; you need to use AU, or shut down and manually copy
over the existing JAR. Hence Ruda's problem reported on nbdev
(DuplicateException) - this is correct behavior.

committed   * Up-To-Date  1.6        
committed   * Up-To-Date  1.7         core/.cvsignore
added       * Up-To-Date  1.1         core/apache-license.txt
committed   * Up-To-Date  1.52        core/build.xml
committed   * Up-To-Date  1.3         core/
committed   * Up-To-Date  1.340      
committed   * Up-To-Date  1.41       
committed   * Up-To-Date  1.209       nbbuild/build.xml
committed   * Up-To-Date  1.17        openide/.cvsignore
committed   * Up-To-Date  1.95        openide/build.xml
committed   * Up-To-Date  1.28        openide/
removed     * Up-To-Date  1.1         openide/org-openide-nbm-license.txt
removed     * Up-To-Date  1.1         openide/
removed     * Up-To-Date  1.1         openide/
committed   * Up-To-Date  1.34       
committed   * Up-To-Date  1.15        openide/www/versioning-policy.html