Bug 152960

Here is an early patch to platform harness, which allows cluster.path configuration based on Jesse's proposal. Sample
projects included as well.

Any feedback, testing, automated tests, etc. are very appreciated. I will describe the implementation in wiki, in the
meantime sample projects give an example. Basically build-impl.xml file for both suites and modules is different and
platform.properties in suite should now contain definition of cluster.path instead of nbplatform.active and
enabled.clusters.

Patch is rather quite incomplete, so far covers only harness (+ nbbuild) changes, IDE still won't cooperate with it, ie.
error badges will be shown and changes to project.xml from IDE will create wrong build-impl.xml. Other not yet working
features:
 - support for pre-7.0 suites (translation of nbplatform.active, etc. to cluster.path)
 - test, build-zip, nbms, jnlp targets 
 - build of NB.org modules (translation of netbeans.dest.dir to cluster.path)
 - paths to NB clusters cannot be specified via nbplatform.active yet 
 - probably many corner cases, like detection when suites are built against different platforms
 - cleanup of unused code
 
After applying the patch, nbbuild and apisupport.harness must be built from sources. Let me know if anyone would prefer
e.g. binaries for a nightly build for testing instead.

Created attachment 74007 [details]
Early patch (harness + nbbuild)

Created attachment 74008 [details]
Sample projects

Looks like a good start to me. Clearly a lot of work remains.

BTW I don't think NbTestCase supports JUnit 4. I could be wrong.

Here is an issue (issue 153249) which is pretty related to improving RCP support. This started out as a Maven issue, but
it relates to library wrapper modules I believe and any support which might embed .jar files in a module. See my last
comments about the problem with ext and common .jar files such as commons logging, log4j, hibernate, and others.

http://www.netbeans.org/issues/show_bug.cgi?id=153249

I mentioned Jesse's name because if I remember correctly he wrote one time that the NB module system should not access
the exact same .jar file from multiple class loaders. Maybe I am mistaken there, but common 3rd party JARs make this
issue more pronounced the more folks we have writing modules for the platform and IDE I imagine. Maybe I'm off my rocker
here.

UI spec proposal added: http://wiki.netbeans.org/EnhancedConfigurationOfNBRCPProjectsUISpec

Created attachment 75469 [details]
Patch for api review

Created attachment 75470 [details]
Sample projects

Created attachment 75722 [details]
Better patch for review (resolved conflict, bugfix)

Generally looks good. (I can't realistically review every line of the patch, but the format spec sounds right at least.)

I guess this patch is not intended to include apisupport.project changes, which are likely large.


[JG01] Having Platforms and Libraries be independent categories looks odd to me. Rather different than other project
types. But UI review can say more.


[JG02] In jnlp.xml, using patterns like **/lib/**/*.jar is probably wrong. For example, this might pick up
...somecluster/ant/lib/ant.jar, which is not a module. The use of the single '*' as the initial path component was
intentional as it matches only direct subdirs of clusters.


[JG03] The code

<condition property="suite.dir" value="${basedir}">
  <not>
    <isset property="suite.dir"/>
  </not>
</condition>

can be expressed more simply as

<property name="suite.dir" location="${basedir}"/>

since Ant will not overwrite a property which is already defined.


[JG04] Current code stores bare cluster names with no numeric prefix and searches for a cluster named "${barename}\d*".
I think it is clearer for "platform" to resolve to "platform8" than for "platform8" to resolve to "platform9".

Thanks for review. Yes, this is harness part only, I'm working on apisupport.project now. 

JG01: The original UI layout used only one category with all clusters merged in one view. In discussion with Tonda we
then decided to split the categories and I don't remember the reason now, maybe Tonda will? I have no strong opinion here.

JG02, JG03: Will do.

JG04: Do you mean that cluster.path could and should contain bare cluster names (bare paths) and harness should seek for
numbered clusters (in addition to exact match)? Will do that as well.

> JG01: The original UI layout used only one category with all clusters merged in one view.
> In discussion with Tonda we then decided to split the categories and I don't remember the reason now,
> maybe Tonda will?

I don't have a strong opinion about the layout. Both approaches work for me. Either two panels (e.g. "Platforms",
"Libraries"), or one panel (called "Libraries", "Classpath" or "Dependencies"?).

One panel is better to have all the dependencies of the project in one place. Two panels allow more space for the
treetable components (as seen in the UI spec ascii art).

> One panel is better to have all the dependencies of the project in one place. Two panels allow more space for the
> treetable components (as seen in the UI spec ascii art).

Yep, I remember now, it was the space. We thought that another 3 buttons would limit size of clusters/modules tree too much.

JG01 - I understand that all this maybe cannot fit in one panel. It just seemed strange to me that these were parallel
panels with no obvious connection, rather than a parent panel with a child panel. (But I don't know which should be the
parent, nor what the labels should be.)

JG04 - yes, that would be my preference. Would be consistent with current behavior (issue #73706).

Created attachment 75773 [details]
Patch with Jesse's comments implemented

Created attachment 75775 [details]
Patch with Jesse's comments implemented

Created attachment 75776 [details]
Patch with Jesse's comments implemented

Which repository are you working against? Are these patches incremental or are there some we should apply before others?
Even with a clean main I get rejections on most of the patch when I try to apply it.

Created attachment 75807 [details]
Sample projects for latest patch (harness152960_3)

Patches are against main trunk and they are not incremental, the last one (harness152960_3.patch) should suffice. The
last three are actually the same patch, I was getting errors when trying to upload attachments so I re-tried it couple
times. What files do conflict? If you don't want to apply patch, I'll integrate it tomorrow, it should show up in
main-golden this week.

If you want to try it, please use latest sample projects (SampleProjects_2.zip) and make sure that nbplatform.active
property in platform.properties points to NB Platform with patched harness (or specify harness.dir property directly).

Created attachment 75839 [details]
File with patch errors from hg

Per my new attachment many changes cause conflicts which have to be manually applied; would be OK if I had more time. I
have tried grabbing the repository again, using update -C etc, and nothing is getting it done. I'll just wait until it
is integrated. From what I can tell things look OK, so I'll just review it once it is in the repository. 

I have noticed different issues applying various hg patches to NB sources though. I don't know if it is a windows versus
Linux versus Mac thing or what though. Jesse, did you apply this patch to a main repository? If so, and if successfully,
what options did you use, can you paste most options from your .hgrc file? Anyways, I am finding Hg harder to work with
patches than CVS myself. I don't imagine those files I'm having issue should be causing problems as it seems Richard is
the only one working on them right now.

Amen, Wade.  I haven't had much luck with patches from Hg either.  I certainly want to participate more, but I'll have 
to wait until these changes are in the nightly builds, or at least figure out some way to check out the Hg repo that 
contains the patches once they're applied.

While to date I have only reviewed the patch itself, I have no problem applying it against a current clone of core-main:

core-main$ hg imp --no-commit /tmp/harness152960_3.patch 
applying /tmp/harness152960_3.patch
core-main$ hg st
M apisupport.harness/nbproject/project.properties
M apisupport.harness/release/build.xml
M apisupport.harness/release/jnlp.xml
M apisupport.harness/release/run.xml
M apisupport.harness/release/suite.xml
M apisupport.harness/taskdefs.properties
M nbbuild/antsrc/org/netbeans/nbbuild/CreateModuleXML.java
M nbbuild/antsrc/org/netbeans/nbbuild/MakeJNLP.java
M nbbuild/antsrc/org/netbeans/nbbuild/MakeMasterJNLP.java
M nbbuild/antsrc/org/netbeans/nbbuild/ModuleListParser.java
M nbbuild/antsrc/org/netbeans/nbbuild/ParseProjectXml.java
M nbbuild/default.xml
M nbbuild/templates/common.xml
M o.n.bootstrap/nbproject/project.properties
A nbbuild/antsrc/org/netbeans/nbbuild/ConvertClusterPath.java
A nbbuild/antsrc/org/netbeans/nbbuild/PathFileSet.java
A nbbuild/test/unit/src/org/netbeans/nbbuild/PathFileSetTest.java

A clone of main should be no different (only offset by a few hours, and not in any of the files affected by this patch).

If you are working on Windows and have turned on CRLF translation mode for checkout, you might need to unix2dos the
patch file to get it to apply; I don't know offhand.

"I am finding Hg harder to work with patches than CVS" - this is odd since CVS does not even include a command to apply
a patch! Of course you can use the plain old "patch" command on an Hg checkout if you prefer. (A Git-format diff can
encode file renames and binary files which /usr/bin/patch cannot handle, but this patch contains neither.)

Either way, back in the CVS days I never had so many issues applying patches whether it was just using patch or
whatever. I'll try unix2dos as yes I have to have CRLF extensions for Windows turned on to work with the NB sources or I
get all kinds of errors and issues and even the Ant build scripts complain and take longer to run (echos and tests etc),
and if you get CRLFs committed then good luck getting your local Hg working again...at least working with the NB sources
that is without a complete refresh. 

Which that really doesn't make much sense either. Things worked back in the CVS days without all the translation and
worry (even if it was patch...I could work on Windows and Linux pretty worry free). Is it related to Python? It can't
handle CRLF and LF each as line feeds the way Java and other things will or something? I have no idea, but Tom and I
don't seem to be the only 3rd parties having Hg patch issues; it does get in the way of contributing. I just had a
similar issue trying to apply a patch to a single file in a different issue and module related to the project properties
dialog resizing incorrectly due to the project customizers preferred size etc which I was helping fix...we even found
issues with that dialog and NB on multiple monitor systems. I had to apply things by hand to try out others code :-S 

I just want to get to the bottom of it. If I figure it out I'll send in some text for updating the contributing patches
page. I don't know though. After running unix2dos I'm now getting:
C:\java\sun\netbeans\sources\hg\main>hg import --no-commit  c:\java\sun\netbeans\sources\patches\harness152960_3.patch
applying c:\java\sun\netbeans\sources\patches\harness152960_3.patch
abort: The filename, directory name, or volume label syntax is incorrect:
C:\java\sun\netbeans\sources\hg\main/nbbuild/antsrc/org/netbeans/nbbuild/ConvertClusterPath.java

I'll keep trying to figure it out. Seems there are issues in using hg on different operating systems or something...at
least patches so far.

I'm not sure what was "worry free" about CVS w.r.t. newlines; I was constantly searching the repo for files mistakenly
committed with CRLF or even CR (often due to people carelessly sharing checkouts between OSs) and trying to normalize
them, breaking annotate/diff/merge across the fix. That is now a thing of the past thanks to the hooks in
hgext.win32text. Maintaining -kb flags was also a huge headache, whereas win32text autodetects binary files.

The "filename...syntax" error is surely Windows-specific (and may be specific to Cygwin if you are using that). Since I
work exclusively on Ubuntu you will need to find another source of advice.

Anyway this is all off-topic; please use nbdev if you need to. There is clearly nothing wrong with the patch attached
here, rather something with your generic Hg config.

Patch integrated into core-main #062f18e44133

If anyone will test the new harness, take a look at SampleProjects_2.zip attachment, notably build-impl.xml for both
modules and suites and platform.properties have new format.

I did a clone of http://hg.netbeans.org/core-main/ at around 1PM CST this afternoon, then built an IDE from that source
using cluster.config=basic.

I downloaded and unpacked the SampleProjects_2.zip file, but I got the following error when trying to build them:

D:\temp\enhanced_rcp_samples\EnhancedRCPCore\build.xml:7: The following error occurred while executing this line:
D:\temp\enhanced_rcp_samples\EnhancedRCPCore\nbproject\build-impl.xml:27: You must specify path to 'platform' cluster in
${cluster.path} property.

I looked at the platform.properties of the suite and saw that the nbplatform.active property had been set to something
unusual.  After setting it back to nbplatform.active=default, I was able to build the sample projects.  I was also able
to set the suite.dir, netbeans.dest.dir and harness.dir properties so that I could use a separate platform in a location
relative to my suite.  No regressions there.

I was able to create a new platform application using the New Project wizard.  Afterwards, I was able to build that with
no problems.

That's a very superficial look but all I had time for today.  I will try and take a closer look at it soon.

> I looked at the platform.properties of the suite and saw that the nbplatform.active property had been set to something
> unusual.  After setting it back to nbplatform.active=default, I was able to build the sample projects.  I was also able
> to set the suite.dir, netbeans.dest.dir and harness.dir properties so that I could use a separate platform in a location
> relative to my suite.  No regressions there.

Thanks a lot for trying this, sorry I didn't specify the guidelines how to use new harness. You've figured most of it
correctly, platform.properties should contain:
* nbplatform.active pointing to valid platform with new harness
** alternatively harness.dir can be specified directly, nbplatform.active can be any valid platform in this case
* cluster.path.raw as path-like structure of clusters "visible" to the project. It can contain absolute or relative (to
suite.dir) paths or paths with prefix "${nbplatform.active.dir}" (typically "${nbplatform.active.dir}\\platform" at
least) which will be resolved against active Nb platform. Clusters can be written in "bare" form i.e. without trailing
numbers.
* disabled.modules work as before
* netbeans.dest.dir, enabled.clusters and disabled.clusters properties are ignored. Only when cluster.path.raw property
is not found, project is regarded as pre-7.0 project and cluster.path is constructed from netbeans.dest.dir,
enabled.clusters and disabled.clusters implicitly.

So in order to enable your apisupport projects to use suite dependencies, change platform.properties as described above
and overwrite nbproject/build-impl.xml file in each project with respective versions for suites and modules from sample
projects. I know that it is inconvenient until UI is ready :-/.

I'll add this info to harness README.

[JG05] I presume that nbplatform.active does not necessarily need to be set at all, right? I.e. so long as you have the
platform cluster somewhere in the cluster path, it is OK:

cluster.path.raw=libs/nb70/platform:libs/nb70/ide


[JG06] I don't much like the name "cluster.path.raw" for a visible and important property living in settings. Can it be
just "cluster.path"? If there is a need inside the build scripts for a separate computed property that would e.g.
include absolute paths and exact cluster numbers, you could use "cluster.path.evaluated" or similar.


[JG07] If both cluster.path and one of netbeans.dest.dir, enabled.clusters, or disabled.clusters are defined, an error
should be reported to avoid confusion.

Integrated into 'main-golden', will be available in build *200901170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/dc57dbbca18a
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #152960 early patch - not for integration

JG05: Yes, nbplatform.active is just a convenience indirectly specifying harness location and allowing to use
${nbplatform.active.dir} as prefix for platform clusters in cluster.path.raw. If none of nbplatform.active, harness.dir
is set, harness is searched for in the same dir as platform cluster as a fallback, otherwise build fails.

JG06: OK, I don't like the name either, I was just too lazy to rename it everywhere. Will do it.
JG07: OK.

Integrated into 'main-golden', will be available in build *200901230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7dda21bb62ba
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #152960: fixed build of pre-7.0 standalone modules

core-main #8eec19b42766 (and others). Basic scenarios work, probably still lots of bugs, testing welcome. Please file
bugs as separate issues.

Integrated into 'main-golden', will be available in build *200903021401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/38d5e584e950
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #152960: customizer and dialogs, no functionality yet

Integrated into 'main-golden', will be available in build *200903070353* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/86a6647f8e7e
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #152960: javadoc for ext. clusters

Integrated into 'main-golden', will be available in build *200903111543* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6fd93ebc2b99
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #152960 bugfix, broken standalone module generation

Integrated into 'main-golden', will be available in build *200903120302* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/08af7d2b657f
User: Jesse Glick <jglick@netbeans.org>
Log: #152960: hotfix for build failure caused by 1dd58418c500.

Integrated into 'main-golden', will be available in build *200906190201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/a29ab4f14d61
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: follow-up of #152960: cluster.path description in harness/README

*** Issue 166588 has been marked as a duplicate of this issue. ***

Oke i like this one. So Good That information u give this to us. Hope with this information. We can help one. Of us. For more better and many better dan before. Thank you. 
http://pkrmas99.site/
http://asik99.site/
http://ratusahabatqq.site/
http://jasaqq.site/
http://negarapoker.site/
http://qqdomino88.site/
http://srnpoker.info/
http://murni99.info/
http://mandiriq.co/
http://nagapkr.site/
http://wargapoker99.site/