geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Gusakov (JIRA)" <...@geronimo.apache.org>
Subject [jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
Date Fri, 01 Sep 2006 22:55:22 GMT
    [ 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

        

Mime
View raw message