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.
http://wiki.netbeans.org/wiki/view/NB6DownloadOptions -The change of Download Options caused that the End2End functionality in Mobility Pack doesn't work out of box. End2End provide easy way for users to generate client to web services or web applications. -IMO, this functionality is one of advantages of NB -we should add the basic Java EE functionality to "NB Java ME" build. What is profiler doing in "NetBeans for Java ME" when it doesn't work with Mobile project?
Lowring as this does not causes exceptions and any missbehavior. It is up to Mobility team do implement functionality which tells user to install J2EE to get End2End support.
changing prority back to P1 because (a) it is a usability issue (b) we have to solve it as soon as possible. Suggested solutions: 1) make subset of J2EE support part of Mobility distribution. Particulary the following updates: Web Applications Web Services Sun Java Systems Application Server 2) remove Mobility end-to-end from all but Full distribution and make it available through update center.
Martin, Installation of the 3 modules you`ve mentioned also requires a LOT of the j2ee modules to be installed together. In sum they are about 70% of the whole enterprise4 cluster. And that is about extra 10Mb for download.
My strong personal opinion: I would recommend to have one more download option -Java SE, Java ME and Java EE but without WVP, UML, SOA. This can cover all I need for example, without need for running for 2nd part of IDE to AU: e.g. if I have Java ME, then I have to go for Java EE anyway and otherwise.. May $.02
Yes, I know. 10Mb would be ok. We need a test build to verify the functionality and download size.
Shipping part of j2ee cluster does not make sense to me, I am against it. Content of installer distribution is a strategic decision. It is not a P1 defect in installer, that just does not make any sense. I understand that mobility team is trying to create a sense of urgency around this, but using a P1 defect is a bit childish. I asked Martin to lower it to P2 just for this reason, I should have asked him to close it, rather. If you want Trung's attention I think it would be better to talk to him.
I don't understand what is strategic on decreasing functionality of the Mobility distro. The End2End functionality has been one of our advantages against the other IDEs. When we lost it (or make it difficult to find) we are loosing customers and the advantage to competition. Anyway, I filled this issue to get clear message from architects+management that we really wanted to lost the End2end functionality. That it was planed not accidental. The decision is your part of the PLC, mine is finding/filling bugs - and that's what I do!
Installer team need to have the decision from architects. And it is better to have quickly - we are too close to Beta 1
As I know, the decision has already been done... Are responsible people working on implementation ? If so please reassign appropriately ... (I don't think Trung is going to fix this, are you ?). Thanks in advance.
Implementation was committed to trunk yesterday. Reassigning to Dima for future processing.
FIXED. Verification on Beta build is necessary.
I'm verifing that the jars (end2end+jsr172) are not presented in the Mobility distro. The AUC part isn't ready yet (I reported issue 115037) - it needs to be resolved before this issue can be verified.
AFAIU, this change affects only Beta build for now, right? The trunk is still the without the change.
Lukas, yes those changes were made only in beta1 branch. I`ve not committed them to trunk. Dmitry
please, merge this functionality to trunk too thank you
Lukas, I do believe that it was a temporary solution for Beta 1. For Beta2 and FCS most probably the problem solution would be revisited.
Lukas, The current solution is temporary according to the best of my knowledge. I assume that in trunk we will implement permanent on as soon as it will be decided. Am I wrong ? L.
We agreed on the merge with Martin R. a few days ago. QE will use trunk for further testing therefore it would be useful for us to have the same code as in Beta1. In this way we can verify fixes and use the same enviroment as Beta users. The merge isn't in hurry. We are still focused on Beta1. However i don't see any major issue that should block us from merging it to trunk. Even in case that it is only temporary solution. OTOH, all the beta1 fixes should be reflected in trunk. Martin R. should speak up if he plans it in different way.
ported to trunk. verify the next daily (>=200709140000).
v