netbeans launcher filters cluster which doesn't exist in the startup time. The
launcher should transmit all declared by relative path. Makes problems in
Autoupdate to handle correctly target clusters declared in NBM header.
Created attachment 29817 [details]
I am adding all clusters including those that does not exists
I have a patch that always adds the cluster. If it contains / it treats it as
a fullpath, otherwise it prepends $progdir/../
Honzo, would such a change be possible also in the windows launcher?
Perhaps. But I won't have time to work on it in the next two weeks. If you can
provide a patch, I can build it, but that's about it.
Reassigning to Radim, new owner of the launcher.
There is no cluster filtering in Windows launchers (netbeans.cpp & app.cpp). All
read values are passed without modification for further processing. Passing back
to Yarda so he can commit his change.
/shared/data/ccvs/repository/ide/launcher/unix/netbeans,v <-- netbeans
new revision: 1.37; previous revision: 1.36
Fixed for unix launchers. I'll trust Radim that windows ones really correctly
interpret non-existing relative clusters.
Was reverted in trunk (1.40) due to other problems it caused, though I am
unconvinced that the issue should be fixed at all. Sounds rather like a bug in
AU that it is unable to create clusters.
Ok, here is the great vision by Jesse and me:
> Jaroslav Tulach wrote:
> > Autoupdate itself cannot append anything to cluster.conf file as it
> > is supposed to not know about that. The cluster.conf is IDE thing,
> > while autoupdate is platform application. You need an API to allow
> > ide/updatecenters to plug into autoupdate.
> Makes sense, but
> > The NBM has a cluster that the launcher knows how to launch, but it
> > does not exist yet. Like profiler or mobility when you download base
> > NetBeans.
> I thought we wanted to use AU to create clusters that are not known in
> advance. Then we could delete the nonexistent cluster names from
> netbeans.clusters. And we could update not just Mobility and Profiler,
> but Collaboration, Visual Web Pack, UML, .... from a regular update
> center without having to enumerate them all when we cut the IDE build.
This is a great vision. I like it. But it will need a bit more work. A bit
from Jirka R. and a bit on the ide/updatecenters side.
> > Of course the API between launcher and autoupdate is a better,
> > however more complicated, solution.
> Seems to me that any solution that means we have to forever hardcode
> cluster names we do not ship, and cannot handle clusters that were
> created after the IDE shipped, is broken and should not even be
> considered - if we are taking the time to try to solve anything.
> I don't see how complicated the API can be. Put in Lookup an impl of
Created attachment 36276 [details]
API between autoupdate and ide/updatecenters to allow extensibility of list of clusters
I believe this change allows us to simplify launcher a bit and address Jesse's
objection against the handling of non-existing clusters. Moreover it gives us
long desired functionality we need - e.g. create new clusters thru autoupdate.
Reviewers please review, I'd like Jirka R. to help me integrate this at the
end of next week.
Looks fine to me.
os.write("\n".getBytes()) => os.write('\n')
Thanks for your comments, I'll integrate the change.
#74947: Introducing an API for communication between autoupdate and launcher
that handles etc/netbeans.clusters
Created attachment 36421 [details]