On an overall level, does Fedora really have all the current Netbeans
dependencies?  The Build-Depends is pretty short.  Does Netbeans ship a copy of
any libraries in source form even, not necessarily jar?

%setup -q -c
find . -type d | xargs -t chmod 755
find . -type f -exec chmod 644 {} ";"
find . -type f \( -iname "*.jar" -o -iname "*.zip" \) | xargs -t %{__rm} -f

Longer term, I'd try to have netbeans generate a clean source tarball/zip rather
than relying on this.

LNS="%{__ln_s}"
MKDIRP="%{__mkdir_p}"
JAVADIR="%{_javadir}"
JAVADOCDIR="$RPM_BUILD_ROOT/%{_javadocdir}/netbeans-platform7"
RMF="%{__rm} -rf"
INS="%{__cp} -r"
NBDIR="$RPM_BUILD_ROOT/%{clusterdir}"
JHJAR=javahelp2.jar
export LNS MKDIRP JAVADIR JAVADOCDIR RMF INS NBDIR JHJAR

A lot of this stuff seems like it could be put into the upstream build system.

%files
%defattr(644,root,root,755)
%dir %{clusterdir}/platform7/
%{clusterdir}/platform7/*

That's it?  There's no /usr/bin/netbeans?  You need to have a .desktop file at
least too.

Oh, I missed that this is just the -plaftorm.  Ignore the last comment.

The dependencies for the platform are java > 1.6.0, javahelp2 and swing-layout

"A lot of this stuff seems like..." - is it a blocker? If it builds, then it 
builds, and that is the most important goal, imho. Btw. The reason you see 
these tricks with environment variables is that we want to share as much as 
possible with the debian packages and these variables represent differences 
between the scripts for RPM based distros and debian.

"A lot of this stuff seems like..." - is it a blocker? 

Nope, not a blocker; we have plenty of spec files with much hairier rules.  Just
a suggestion.

Looking at the upstream source, I see a lot of empty directories with names of
other projects:

drwxr-xr-x mslama/mslama       0 2008-01-29 11:46
netbeans-platform-6.0.1/libs/jsr223/
-rw-r--r-- mslama/mslama    2169 2007-09-26 16:48
netbeans-platform-6.0.1/libs/lucene/

etc.  Do any these get downloaded and built during 'make build'?  Be aware that
the Fedora build system (koji) has no Internet access.  The right thing to do is
get everything packaged as separate RPM components - this ensures that we only
need to ship one new package when there is a security or reliability issue, as
well as helping reduce duplication of code upstream.

Yes, we use separate RPMs for each component (like javahelp2, lucene2 - only 
for the IDE, atd.). No, we do not need internet connection. This is 
experimentally verified, these SRPMS were successfully built on Mandriva's 
cooker and I expect their build system to have similar restrictions.

Btw. if we resolve issues with the platform and manage to build it on koji, 
I'll provide SRPMS for IDE and other libraries. This platform case is here to 
estimate how much work that will be.

When I try to build with:

mock -r fedora-devel-x86_64 libnb-platform7-6.0.1-2.src.rpm

I get this error in build.log:

error: line 3: Tag takes single token only: Release:	%mkrel 2

I'm not familiar with %mkrel; is it from another RPM system?

Re: "%mkrel 2" - yes, it has been told me to use that by mandriva guys, I 
lived in an impression that it is some standard makro that resolves to 2mdv on 
mandriva and 2fc9 on fedora. If you tell me what to use instead, I can use 
that.

On the other hand it would not be bad if you defined %mkrel somewhere 
globally, but I can imagine it would have bigger impact and required more 
reviews than only including this package.

The package's name differs from upstream - current name, libnb-platform7, is
quite ugly. Why not to name it netbeans-platform?

Few notes:

* You should drop epoch field completely. 
* BuildRoot should be changed to something like

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

* You should use %{dist} tag instead of %mkrel

Release:        2%{?dist}

* Drop macro %source_top - it's not used.
* Drop macro %section - it's not used.
* I don't understand the purpose of %clusterdir macro - why not to substitute
%{_datadir}/netbeans ?

In any case - great work! Thanks.

Are you planning to push NetBeans to Fedora?

OK to almost all your comments. I'll change the spec.

Re. "Are you planning to push NetBeans to Fedora?" - yes, that is what I'd 
like to! Now tell me what I need to do to make that happen? If I attach 
modified spec, will somebody apply it? Or will I get access to your version 
control & build system to do it myself? Which of these and when?

Basically we iterate the spec, once it's ready there is a final review.  At that
point you will get a Fedora account, a CVS directory and you can make changes
and initiate builds.

So yes, please post a updated .spec and SRPM files after the fixes above.

Updated:

Spec URL: http://www.xelfi.cz/download/dev/SRPMS/netbeans-platform.spec
SRPM URL: 
http://www.xelfi.cz/download/dev/SRPMS/libnb-platform7-6.0.1-3.src.rpm

Things that I have not changed: %{clusterdir} - it is easier to move NetBeans 
around, and anyway it is just local variable, not visible from outside.

The name libnb-platform7 signals two things: 1. this is just a library, 
nothing to be executed. It is version 7 of the platform, when we release new 
incompatible version we make it 8.

This has a dependency on java-rpmbuild that isn't in Fedora, I think we ran into
that somewhere else?

But we need javahelp2, so I'll take a look at #439263 first.

Hi Jaroslav, I noticed that you've also submitted this to JPackage:
https://www.jpackage.org/bugzilla/show_bug.cgi?id=197

We should probably do the fixes there and then once it's done synchronize with
Fedora.

I working with jpackage simplifies something for me, then OK. Anyway I have 
changed the javahelp2 package, which was the last blocker for this package, as 
far as I remember. So maybe you could just check the latest submission for 
errors?

Jaroslav, please remove the java-rpmbuild build requirement (or propose
java-rpmbuild for inclusion in Fedora, if appropriate) so that this review can
proceed.

Has there been any more progress with this package?

Review Request for NetBeans Platform 6.1:
https://bugzilla.redhat.com/show_bug.cgi?id=456341

*** This bug has been marked as a duplicate of bug 456337 ***