You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Oleg Gusakov (JIRA)" <de...@geronimo.apache.org> on 2006/09/02 00:55:22 UTC
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar
support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432253 ]
Oleg Gusakov commented on GERONIMO-2324:
----------------------------------------
SharedLib might not be an ideal solution as David quite reasonably indicated, but here is the use case:
* I develop a WAR project under Eclipse
* this project depends on 15 Eclipse JAR projects (just java code) I need to debug
* this project depends on 500 JAR artifacts that are attached (in Eclipse) via either Eclipse external jar or Maven plugin dependency
* I need to debug my WAR under Geronimo
** all my dependencies, both Eclipse project references and external JARs should be available
** if I change a java file in one of the referenced projects - it should be re-published into Geronimo on the fly by the plugin
** I may choose to convert one of those 500 dependency JARs into a full blown Eclipse project so
*** plugin may have to drop that jar from Geronimo
*** redeploy it as an Eclipse project
Controlling all those jars and classes via Maven-like repository migh be a stretch - by definition Maven repository hosts finalized artifacts that have passed unit tests. I, on the contrary, am trying to quickly manupulate half-baked code that really belongs to IDE, not even a JAR file.
So SharedLib seems to be a logical candidate. Or some other GBean that would allow easy classloading changes, especially given the fact that all manipulations originate not from a user but from a plugin that is fairly well tested ;)
Another consideration - visibility of the published classes. It does not matter that much for development deployments. But even here - I can envision rather complex applications desiring to limit the visibility of their artifacts.
This leads to another idea - there should a way to specify where this "SharedDevLib" classloaders attaches - server-wide, particular EAR or, even WAR.
> Allow in-place and exploded jar support for sharedlib
> -----------------------------------------------------
>
> Key: GERONIMO-2324
> URL: http://issues.apache.org/jira/browse/GERONIMO-2324
> Project: Geronimo
> Issue Type: RTC
> Security Level: public(Regular issues)
> Components: deployment
> Affects Versions: 1.1
> Reporter: Sachin Patel
> Assigned To: Sachin Patel
> Fix For: 1.x
>
> Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch
>
>
> The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime.
> Perhaps we can have a properties file insie the shared lib that have external entries in them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira