[Tomcat-dev] JK 1.2.18 isapi_redirect installer builds

I hate to do this, but I have to say no, until sometime next week; right now
I'm swamped, and the abortive 1.2.17 and svn mail interference didn't help
much while trying to clear this backlog of work-work :)

InstallShield has a build-only environment, it's a matter of getting the
appropriate license from InstallShield to deploy it for the benefit of any
ASF project. I lost some old email archives that started the discussion,
but I can try to revive those early in August.

Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Just out of interest, is there any motivation to switch to Nullsoft's
Installer for future mod_jk/isapi_redirect releases? Given that
tomcat's win32 installer uses this, and it's free, I would think that
would be a better option than InstallShield. (Or am I missing something
about the advantages of InstallShield over Nullsoft?)


Trent.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Nullsoft lacks advanced IIS virtual directory
creation/deletion. I suppose it can be done with
multiple .vbs scripts.

Anyhow, since Microsoft has a tendency to change
the Metadatabase keys (ROOT, Root) I'm less and
less in favor of any installer.
But you are free to participate :)

Regards,
Mladen.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

EWWW - no :) They are keys. Does Nullsoft provide for arbitrary msi
table data for the IIS registration virtual directory registration?
Opening our previous installer in orca should let you browse where the
appropriate registration keys are.

Any tool that doesn't provide arbitrary table data for the installer schema
(including IS - which happens to provide it) isn't worth investigating.
Any tool that does let us set up arbitrary columns for the .msi that is
being prepared should allow us to manually provide more advanced iis,
com, net registration data, even if there's no eligant support.

Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

No, they are not. Neither are filters :)

Not what I ment. Found binIISHelper - sort of bogus ;-)

I don't see any reason not to create out own, or use the columns to add our
Registry entries to IIS for virtual directories, or explore if a later version
of .msi provides this functionality. InstallShield 10 often did things 'it's
own way' rather than relying on the full msi schema, but was nice about adding
helpers for things that had no efficient way to do them.

I'd avoid vbs ;-) Preferable to create a lightweight .dll helper binary before
considering that. I presume the binIISHelper is InstallShields, since they
create the tables ISIISCommon and ISWebSite, namespace protecting them.




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Nullsoft's
that
Nullsoft doesn't provide anything MSI-related at all ;-) It simply
compiles your script directly into an executable. The reason I
suggested it as an alternative to InstallShield is because there are
probably more users that could contribute to building/maintaining an
.nsi script vs. an .ism (that requires a commercial license). Tomcat's
installer is based on Nullsoft, after all.
Yeah, I opened up isapi_redirect.msi with a copy of Wise I had lying
around; I assume you're referring to the two entries in the ISIISCommon
table?
The thing I don't like about MSI, to quote Joel Spolsky, is that it
suffers from ``leaky abstractions''[1]; That is, a developer should be
able to leverage the abstraction provided by MSI tables such that they
never have to know the underlying details behind how COM/.NET components
are registered, how IIS virtual directories are created, etc. In
reality, the reverse applies; the people that know how to do those tasks
manually would rarely know how to represent the information in MSI
tables.

So, although Nullsoft doesn't allow you to utilize arbitrary table data,
it does allow you to pretty much anything else, so you could manually do
IIS virtual directory creation if need be (and you've got the added
benefit of more people likely to know and be able to build .nsi
scripts).


Trent.

[1]: http://www.joelonsoftware.com/articles/LeakyAbstractions.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org