Re: File locations: EAR, WAR, XML datasource
> Ultimately, here is the use case I am looking at:
>
> - a user decides they want a particular package (e.g. xwiki, a WAR file)
>
> - they type apt-get install xwiki
Easy.
> - the package depends on other packages: j2ee-war-container and
> jdbc-driver, and it recommends relational-database
Easy.
> - apt satisfies those dependencies by installing Tomcat, MySQL JDBC driver,
> and MySQL server
Easy.
> - during the xwiki package installation, the install script sees that the
> MySQL JDBC package is installed, and it offers to create a datasource for
> that driver (and create a database too) - the user accepts this option
The hard part. See below...
> - finally, the user is told that their Tomcat may require a restart
If we go that far we can this for the user too.
> Now let us consider one modification to this use case: the user already has
> JBoss installed. In this case, JBoss already satisfies the dependency
> j2ee-war-container, so apt doesn't try to install Tomcat.
Easy, normal APT job.
> I realise that there are users who want much more control over their
> application servers - I am one of them. Nonetheless, I think that what I'm
> proposing is feasible, even if it may take a little thought and time to
> fully implement. If Debian provides this infrastructure, then there is a
> real possibility that vendors will want to release their products on
> Debian, as the users will deploy them more easily.
>
> Also, there is no need for any of this to be mandatory - for instance, the
> user would still have the option of manually installing JDBC driver JAR
> files, and manually configuring the application server to create a
> datasource.
>
> Datasource creation is server specific - but maybe we can offer a
> generalised approach, and each packaged application server can (eventually)
> provide a script to implement it?
I would like to have this all designed and all features check that they
are implementable before we start to implement it. This way we make sure
that dont need to stop after doing half the job because the other half
is not solvable. E.g. the creation of container specific datasource
definitions looks really complicated to me.
Cheers,
Michael
Reply to: