6.7 thinks .../<cluster>/modules is a cluster?

[Ivan Soleimanipour-4]

I switched from 6.5.1 to 6.7 and am building against the 6.5.1 based "platform" that we
base SunStudio on and I get this:

/net/djomolungma/nb-ws/netbeans-6.7/harness/build.xml:165: The module com.sun.tools.swdev.toolscommon cannot be compiled against because it is part of the cluster /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1/modules which is not part of cluster.path in your suite configuration.
Cluster.path is: [/export/home/gdbgui/dev_install/sparc-S2/netbeans/ide10, /export/home/gdbgui/dev_install/sparc-S2/netbeans/platform9, /export/home/gdbgui/dev_install/sparc-S2/netbeans/nb6.5, /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1, /export/home/gdbgui/dev_install/sparc-S2/netbeans/gsf1, /export/home/gdbgui/dev_install/sparc-S2/netbeans/cnd2]

Note where  it says
... because it is part of the cluster /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1/modules
it has tacked on /modules.
Otherwise cluster.path _does_ contain

/export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1

What's with this tacked-on /modules?

[Ivan Soleimanipour-4]

On 07/02/09 16:59, Ivan Soleimanipour wrote:


Could this be the reason? com.sun.tools.swdev.toolscommon is in
autoload/com-sun-tools-swdev-toolscommon.jar and a .. from
that would yield modules instead of the actual cluster dir.

Is the autoload subdirectory de-mode now?

> I switched from 6.5.1 to 6.7 and am building against the 6.5.1 based
> "platform" that we
> base SunStudio on and I get this:
>
> /net/djomolungma/nb-ws/netbeans-6.7/harness/build.xml:165: The module
> com.sun.tools.swdev.toolscommon cannot be compiled against because it is
> part of the cluster
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1/modules which
> is not part of cluster.path in your suite configuration.
> Cluster.path is:
> [/export/home/gdbgui/dev_install/sparc-S2/netbeans/ide10,
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/platform9,
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/nb6.5,
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1,
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/gsf1,
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/cnd2]
>
> Note where  it says
> ... because it is part of the cluster
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1/modules
> it has tacked on /modules.
> Otherwise cluster.path _does_ contain
>
> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1
>
> What's with this tacked-on /modules?
>

[Richard Michalsky]

Ivan Soleimanipour wrote:
> On 07/02/09 16:59, Ivan Soleimanipour wrote:
>
>
> Could this be the reason? com.sun.tools.swdev.toolscommon is in
> autoload/com-sun-tools-swdev-toolscommon.jar and a .. from
> that would yield modules instead of the actual cluster dir.
>
> Is the autoload subdirectory de-mode now?
Nope, I guess it is a bug, please file an issue, I'll fix it.
R.

>
>
>> I switched from 6.5.1 to 6.7 and am building against the 6.5.1 based
>> "platform" that we
>> base SunStudio on and I get this:
>>
>> /net/djomolungma/nb-ws/netbeans-6.7/harness/build.xml:165: The module
>> com.sun.tools.swdev.toolscommon cannot be compiled against because it
>> is part of the cluster
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1/modules
>> which is not part of cluster.path in your suite configuration.
>> Cluster.path is:
>> [/export/home/gdbgui/dev_install/sparc-S2/netbeans/ide10,
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/platform9,
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/nb6.5,
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1,
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/gsf1,
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/cnd2]
>>
>> Note where  it says
>> ... because it is part of the cluster
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1/modules
>> it has tacked on /modules.
>> Otherwise cluster.path _does_ contain
>>
>> /export/home/gdbgui/dev_install/sparc-S2/netbeans/sside1
>>
>> What's with this tacked-on /modules?
>>
>

[Jesse Glick]

Ivan Soleimanipour wrote:
> Is the autoload subdirectory de-mode now?

I'm not sure what "de-mode" means, but putting module JARs in autoload/ or eager/ subdirectories has been deprecated for years now.

[Ivan Soleimanipour-4]

[ cc'ing Yarda, the philosophical API guy ]

Jesse Glick wrote:
> Ivan Soleimanipour wrote:
>> Is the autoload subdirectory de-mode now?
>
> I'm not sure what "de-mode" means,

It's French for "de-fashioned".

> but putting module JARs in autoload/ or eager/ subdirectories has been
> deprecated for years now.
>

So I figured.
However, if you take away the IDE wizards and look just at the xml specs
the configuration
.xml can specify an arbitrary path to the module jar. And if that is
"allowed" then
the system as a whole should work correctly.

This is somewhat of a general philosophical principle.
We design a certain system (e.g. the module system) with certain
degrees of freedom which span a certain "space".
Then, on top of that we have the IDE and it's mayriad of wizards which
typically
work within a more constrained sub-space.
This slightly out-of-date cluster I have is valid in module-space but not in
module-wizard-space.
How much am I allowed to ... complain?

[arittner]

Hi!



Click: How to update NetBeans Platform Application silently (http://blogs.sun.com/rechtacek/entry/how_to_update_netbeans_platform)



hth, if I understand right what you mean :-)



br, josh.

------------------------
JNBB/BeanDev: Das deutsche Blog zur NetBeans Platform (http://www.sepix.de/blogs/blogrittner)

[Jesse Glick]

Ivan Soleimanipour wrote:
> if you [...] look just at the xml specs
> the configuration
> ..xml can specify an arbitrary path to the module jar. And if that is
> "allowed" then
> the system as a whole should work correctly.

The _module system_ works correctly with an arbitrary path to a module JAR (so far as I know). The _Ant-based module build harness_ requires modules to be
${cluster}/modules/${code.name.base.dashes}.jar. Relaxing that restriction would require some work and a lot of testing and I don't think we plan to do so.