I think I'd go with it like this:
If we detect a file in the deploy/ directory with the extension '.jar',
AND the JAR's manifest does NOT contain any OSGi headers, THEN we assume
that it's a plain-old-jar, and perform an auto-wrap.
Sounds pretty safe (and very usable!) to me, no?
On 11/01/2011 13:04, Guillaume Nodet wrote:
That could be a good idea, but I'm not sure how to identify soemthing by the
negative without screwing the whole thing.
I mean a war is a jar too, a kar is a zip file, a jbi archive is also a zip
file. It would be a bit of a catch-everything, so I'm not really sure if
that would work well.
On Tue, Jan 11, 2011 at 01:51, Adrian Trenaman<[email protected]>wrote:
Hmmm.
I think I recall Guillaume saying that you could achieve this by just
dropping them into a lib/ext directory?
However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
into the deploy directory, then it should depoy using wrap (and making all
dependencies marked for optional resolution to assist ease of use).
Best,
Ade.
On 10/01/2011 21:46, Charles Moulliard wrote:
Hi,
I would like to know if we have a property that we can setup to
register additional jar librairies (defined in a client folder
directory) like we do for JRE runtime libraries and expose them as
packages ? If this is not the case, could the hot "deploy" folder be
the alternative ?
Regards,
Charles Moulliard
Sr. Principal Solution Architect - FuseSource
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
--
Adrian Trenaman, Sr. Principal Solution Architect
FuseSource
Phone: +353-86-6051026
Email: [email protected]
Web: http://trenaman.blogspot.com, http://fusesource.com
Twitter: adrian_trenaman
--
Adrian Trenaman, Sr. Principal Solution Architect
FuseSource
Phone: +353-86-6051026
Email: [email protected]
Web: http://trenaman.blogspot.com, http://fusesource.com
Twitter: adrian_trenaman
