Re: GERONIMO-1526
It tracks revisions, so you can automatically merge two branches with out needing to know what revisions to use.This is important, because it is generally easier to resolve conflicts when working on a development branch, by pulling in the latest changes from your source tree and then resolving the changes wrt your local tree. If you resolve the conflicts when you pull in changes, when you push them back (merge your feature back into the source) then you will have very few (or no) conflicts.http://svk.elixus.org/?MergeFeaturesSVK also has some nice features to show you what would conflict before actually applying conflict markers to files, so its easy to see what needs to be handled specially and what can just be automatic.SVK is a good tool to augment anyones existing SVN development environment. It brings some rich merging and decentralized version control features that can be used with out altering your existing workflow... meaning you don't need IDE support for SVK or have to change your workspaces from SVN to SVK.Though... if IDE's would start to support SVK, then I would probably recommend using it over SVN... but its not there yet, maybe in 6mo or a year? Dunno.Anyways, I will write a howto with a simple example... and you'll be amazed at how easy it is to merge SVN with SVK.:-)--jasonOn Aug 24, 2006, at 11:22 AM, Sachin Patel wrote:Agree. Will create a branch. Yes if you could post some instructions on svk that would be great. BTW, what more does svk do compared to svn merge?On Aug 24, 2006, at 2:18 PM, Jason Dillon wrote:I agree, this is what branches are good for.I have been meaning to write a howto doc about how to use svk to merge branches (not to develop, but just to merge). It works really well for these types of feature branches to manage conflicts and to keep feature branches up to date with the latest from the source tree. Maybe I'll get to that this weekend.--jasonOn Aug 24, 2006, at 11:10 AM, Dain Sundstrom wrote: For a change of this size, I suggest you cut a branch as it will let everyone see you work in progress, and I assure it will save you during development as you can rollback bad ideas :)-dainOn Aug 24, 2006, at 10:21 AM, Sachin Patel wrote: Please review the following changes, thus far. Please review the changes carefully to be sure I did not break an existing function.The bulk of this change is:(1) Allows a DeployableModuleImpl class to be set for a single deployment via the DeploymentManager (currently the factory only loads the default, need some advice on how best to load the class for other impls)(2) Introduces DefaultDeployableModule implementation of DeployableModule(2) Changes the use of and passing of JarFile throughout the entire deployment process with DeployableModule.Next I plan to fix all the tests that are now broken, then start plugging in a new Impl of DeployableModule for Eclipse support and see if we need to tweak add/remove methods to the interface as I'm not convinced yet that all the methods currently are sufficient. This is where the bulk of the work will be so feel free to help out if interested :).-sachin
Re: GERONIMO-1526
Agree. Will create a branch. Yes if you could post some instructions on svk that would be great. BTW, what more does svk do compared to svn merge?On Aug 24, 2006, at 2:18 PM, Jason Dillon wrote:I agree, this is what branches are good for.I have been meaning to write a howto doc about how to use svk to merge branches (not to develop, but just to merge). It works really well for these types of feature branches to manage conflicts and to keep feature branches up to date with the latest from the source tree. Maybe I'll get to that this weekend.--jasonOn Aug 24, 2006, at 11:10 AM, Dain Sundstrom wrote: For a change of this size, I suggest you cut a branch as it will let everyone see you work in progress, and I assure it will save you during development as you can rollback bad ideas :)-dainOn Aug 24, 2006, at 10:21 AM, Sachin Patel wrote: Please review the following changes, thus far. Please review the changes carefully to be sure I did not break an existing function.The bulk of this change is:(1) Allows a DeployableModuleImpl class to be set for a single deployment via the DeploymentManager (currently the factory only loads the default, need some advice on how best to load the class for other impls)(2) Introduces DefaultDeployableModule implementation of DeployableModule(2) Changes the use of and passing of JarFile throughout the entire deployment process with DeployableModule.Next I plan to fix all the tests that are now broken, then start plugging in a new Impl of DeployableModule for Eclipse support and see if we need to tweak add/remove methods to the interface as I'm not convinced yet that all the methods currently are sufficient. This is where the bulk of the work will be so feel free to help out if interested :).-sachin
Re: GERONIMO-1526
I agree, this is what branches are good for. I have been meaning to write a howto doc about how to use svk to merge branches (not to develop, but just to merge). It works really well for these types of feature branches to manage conflicts and to keep feature branches up to date with the latest from the source tree. Maybe I'll get to that this weekend. --jason On Aug 24, 2006, at 11:10 AM, Dain Sundstrom wrote: For a change of this size, I suggest you cut a branch as it will let everyone see you work in progress, and I assure it will save you during development as you can rollback bad ideas :) -dain On Aug 24, 2006, at 10:21 AM, Sachin Patel wrote: Please review the following changes, thus far. Please review the changes carefully to be sure I did not break an existing function. The bulk of this change is: (1) Allows a DeployableModuleImpl class to be set for a single deployment via the DeploymentManager (currently the factory only loads the default, need some advice on how best to load the class for other impls) (2) Introduces DefaultDeployableModule implementation of DeployableModule (2) Changes the use of and passing of JarFile throughout the entire deployment process with DeployableModule. Next I plan to fix all the tests that are now broken, then start plugging in a new Impl of DeployableModule for Eclipse support and see if we need to tweak add/remove methods to the interface as I'm not convinced yet that all the methods currently are sufficient. This is where the bulk of the work will be so feel free to help out if interested :).
Re: GERONIMO-1526
For a change of this size, I suggest you cut a branch as it will let everyone see you work in progress, and I assure it will save you during development as you can rollback bad ideas :) -dain On Aug 24, 2006, at 10:21 AM, Sachin Patel wrote: Please review the following changes, thus far. Please review the changes carefully to be sure I did not break an existing function. The bulk of this change is: (1) Allows a DeployableModuleImpl class to be set for a single deployment via the DeploymentManager (currently the factory only loads the default, need some advice on how best to load the class for other impls) (2) Introduces DefaultDeployableModule implementation of DeployableModule (2) Changes the use of and passing of JarFile throughout the entire deployment process with DeployableModule. Next I plan to fix all the tests that are now broken, then start plugging in a new Impl of DeployableModule for Eclipse support and see if we need to tweak add/remove methods to the interface as I'm not convinced yet that all the methods currently are sufficient. This is where the bulk of the work will be so feel free to help out if interested :).
Re: GERONIMO-1526
Right, I understand the concerns about using URLs. The point I was trying to make was there isn't a nice clean way to do this. Or at least I couldn't think of a way. The builders won't be able to purely rely on the DeployableModule interface for resolving and processing a module wether its a JarFile or an exploded IDE specific filestructure.So since URLs are not an option we can't represent paths inside jars or paths in a directory in a common way. So inside our builders, taking a more simpler ConnectorBuilder for example... the following piece of code cannot be pushed out into a call in the DeployableModule interface... Enumeration entries = moduleFile.entries(); while (entries.hasMoreElements()) { ZipEntry entry = (ZipEntry) entries.nextElement(); URI target = targetURI.resolve(entry.getName()); if (entry.getName().endsWith(".jar")) { earContext.addInclude(target, moduleFile, entry); } else { earContext.addFile(target, moduleFile, entry); } }and in all the module builders where this type of traversing is done, we will have to have something like...if(deployableModule.isArchived()) {JarFile moduleFile = new JarFile(deployableModule.getRoot());//then do code above} else {File[] = deployableModule.getResources() //moduleFile being an impl of DeployableModule//traverse through each file entry and do similar to above to add to earContext.}rather then be able to use getResources() on the deployableModule regardless of wether its an archive or something else. Hope that helps.So if this is acceptable, I can proceed. On Aug 23, 2006, at 3:39 PM, Jacek Laskowski wrote:On 8/23/06, Sachin Patel <[EMAIL PROTECTED]> wrote: So I've started to make these changes, but it looks like we may have to useURL's in the interface, unless anyone else has any other suggestions due tothe problems dain mentioned with using URLs. Taking the EARConfigBuilderfor example... ideally I'd like to push out the code that traverses throughthe zip entries and let the DeployableModule.getResources() handle this sothe builders only have do deal with the interface and not a specificimplementation such as a jar/zip file. I like your proposal especially after a few days looking at OpenEJBcode and wire an annotation support in. I'm wondering how OpenEJBcould use it once it's introduced in Geronimo?Besides, I don't understand the above comment of yours above. SinceDain has already stated his concerns about File vs URL why do you needmore to come? I think I didn't fully follow the note about zip fileshandling. Would you mind to elaborate a bit?Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin
Re: GERONIMO-1526
On 8/23/06, Sachin Patel <[EMAIL PROTECTED]> wrote: So I've started to make these changes, but it looks like we may have to use URL's in the interface, unless anyone else has any other suggestions due to the problems dain mentioned with using URLs. Taking the EARConfigBuilder for example... ideally I'd like to push out the code that traverses through the zip entries and let the DeployableModule.getResources() handle this so the builders only have do deal with the interface and not a specific implementation such as a jar/zip file. I like your proposal especially after a few days looking at OpenEJB code and wire an annotation support in. I'm wondering how OpenEJB could use it once it's introduced in Geronimo? Besides, I don't understand the above comment of yours above. Since Dain has already stated his concerns about File vs URL why do you need more to come? I think I didn't fully follow the note about zip files handling. Would you mind to elaborate a bit? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: GERONIMO-1526
So I've started to make these changes, but it looks like we may have to use URL's in the interface, unless anyone else has any other suggestions due to the problems dain mentioned with using URLs. Taking the EARConfigBuilder for example... ideally I'd like to push out the code that traverses through the zip entries and let the DeployableModule.getResources() handle this so the builders only have do deal with the interface and not a specific implementation such as a jar/zip file.Any alternative suggestions? Or for now would it be acceptable to keep in the builders the processing of ZipFiles and simply have if/else statements all over the place? On Aug 22, 2006, at 8:14 AM, Sachin Patel wrote:Ok thanks for the clarification.On Aug 21, 2006, at 8:13 PM, Dain Sundstrom wrote:On Aug 21, 2006, at 4:11 PM, Sachin Patel wrote: On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote: Thanks. I have a few questions/issues...Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important. Ok, This is where I value your input. There could be definitely a distinction from a tools perspective, as the java output folder could only contain .class files and not resources and metadata. From a server runtime perspective I wasn't 100% sure as Looking at AbstractWebModuleBuilder.installModule(...), resources are added to the module context either via addFile(), addInclude() and addToClasspath(). So I assume addFile() and addInclude() also adds these to the classloader? If there does not need to be a separation then yes, we can combine both methods. I think I see the disconnect. When I hear the word resources, I think of additional non-class files available via the class loader, but they all end up in the class loader bucket. In the case of a web application, we have two buckets: the class loader and the web app context. The former is the same for all modules, and the latter contains files that are accessible via http.If that is the case, I think we need to keep the separation, but I'm not sure "resource" is the best name given the level of confusion we have already seen.-dain -sachin -sachin
Re: GERONIMO-1526
Ok thanks for the clarification.On Aug 21, 2006, at 8:13 PM, Dain Sundstrom wrote:On Aug 21, 2006, at 4:11 PM, Sachin Patel wrote: On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote: Thanks. I have a few questions/issues...Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important. Ok, This is where I value your input. There could be definitely a distinction from a tools perspective, as the java output folder could only contain .class files and not resources and metadata. From a server runtime perspective I wasn't 100% sure as Looking at AbstractWebModuleBuilder.installModule(...), resources are added to the module context either via addFile(), addInclude() and addToClasspath(). So I assume addFile() and addInclude() also adds these to the classloader? If there does not need to be a separation then yes, we can combine both methods. I think I see the disconnect. When I hear the word resources, I think of additional non-class files available via the class loader, but they all end up in the class loader bucket. In the case of a web application, we have two buckets: the class loader and the web app context. The former is the same for all modules, and the latter contains files that are accessible via http.If that is the case, I think we need to keep the separation, but I'm not sure "resource" is the best name given the level of confusion we have already seen.-dain -sachin
Re: GERONIMO-1526
On Aug 21, 2006, at 4:11 PM, Sachin Patel wrote: On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote: Thanks. I have a few questions/issues... Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important. Ok, This is where I value your input. There could be definitely a distinction from a tools perspective, as the java output folder could only contain .class files and not resources and metadata. From a server runtime perspective I wasn't 100% sure as Looking at AbstractWebModuleBuilder.installModule(...), resources are added to the module context either via addFile(), addInclude() and addToClasspath(). So I assume addFile() and addInclude() also adds these to the classloader? If there does not need to be a separation then yes, we can combine both methods. I think I see the disconnect. When I hear the word resources, I think of additional non-class files available via the class loader, but they all end up in the class loader bucket. In the case of a web application, we have two buckets: the class loader and the web app context. The former is the same for all modules, and the latter contains files that are accessible via http. If that is the case, I think we need to keep the separation, but I'm not sure "resource" is the best name given the level of confusion we have already seen. -dain
Re: GERONIMO-1526
On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote:Thanks. I have a few questions/issues...Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important.Ok, This is where I value your input. There could be definitely a distinction from a tools perspective, as the java output folder could only contain .class files and not resources and metadata. From a server runtime perspective I wasn't 100% sure as Looking at AbstractWebModuleBuilder.installModule(...), resources are added to the module context either via addFile(), addInclude() and addToClasspath(). So I assume addFile() and addInclude() also adds these to the classloader? If there does not need to be a separation then yes, we can combine both methods.I think using URLs instead of files, is going to be very difficult. We had tons of problems dealing with paths containing spaces and urls. IIRC we had to encode and decode URLs all the time. Also, some deployers need to scan the directories. For example, the RAR deployer needs to add all jar files in the archive/directory to the class path. In Jee5 ear files we need to scan for all nested modules.I find the method name isBinary confusing. Can we use something like isArchived instead?Certainly.-dainOn Aug 21, 2006, at 1:16 PM, Sachin Patel wrote: Doh, sorry, guess some javadoc would help :)... So basically the idea is to be able to represent a deployable object, that can be either a jar, or some custom structure specific to a given IDE/build environemnt.public interface DeployableModule { /** * uri of the module, foo.ear, if a nested module then foo.ear/foo.war */ String getURI(); /** * root url of the module, if isBinary then would return absolute URL of the archive, otherwise * the root folder of the module. * @return */ URL getRoot(); /** * returns all the URLs that provide content to this module (non .class files) if isBinary then this would return * empty array * @return */ URL[] getResourceFolders(); /** * returns all the URLs that contai, if isBinary then this would return an empty array * @return */ URL[] getClassesFolders(); /** * Returns true if this is a binary module (JarFile) */ boolean isBinary(); /** * returns nested modules, so for an ear file, would return all its contained modules, for a web module, entries web-inf/lib entries */ DeployableModule[] getModules();}On Aug 21, 2006, at 3:57 PM, Dain Sundstrom wrote: Some java docs would help me understand what these methods are supposed to do.-dainOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote: For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin -sachin -sachin
Re: GERONIMO-1526
I think it is fine to use File for now... its simpler... though I'd still like to entertain the idea of using VFS to abstract all things file... --jason On Aug 21, 2006, at 2:35 PM, Dain Sundstrom wrote: On Aug 21, 2006, at 1:39 PM, Jason Dillon wrote: On Aug 21, 2006, at 1:31 PM, Dain Sundstrom wrote: I think using URLs instead of files, is going to be very difficult. We had tons of problems dealing with paths containing spaces and urls. IIRC we had to encode and decode URLs all the time. Also, some deployers need to scan the directories. For example, the RAR deployer needs to add all jar files in the archive/directory to the class path. In Jee5 ear files we need to scan for all nested modules. Ya maybe... I was just thinking about deploying from things other than files, like an http:// address or nested jar, or some other custom protocol. Using URL allows flexibility by abstraction... where using File binds you to files, since we have no way to augment them. I understand. Originally, I wanted the deployers to work that way also. Then after reading the source for URL, it occurred to me that the VM downloads the content to the local file system anyway, so if we download them ourselves it is equivalent. Actually, doing it ourselves has a lot of benefits. The VM likes to cache urls in a cache you can't flush, so redeploy tends to break. Also File is just easier to use than URL. -dain
Re: GERONIMO-1526
On Aug 21, 2006, at 1:39 PM, Jason Dillon wrote: On Aug 21, 2006, at 1:31 PM, Dain Sundstrom wrote: I think using URLs instead of files, is going to be very difficult. We had tons of problems dealing with paths containing spaces and urls. IIRC we had to encode and decode URLs all the time. Also, some deployers need to scan the directories. For example, the RAR deployer needs to add all jar files in the archive/directory to the class path. In Jee5 ear files we need to scan for all nested modules. Ya maybe... I was just thinking about deploying from things other than files, like an http:// address or nested jar, or some other custom protocol. Using URL allows flexibility by abstraction... where using File binds you to files, since we have no way to augment them. I understand. Originally, I wanted the deployers to work that way also. Then after reading the source for URL, it occurred to me that the VM downloads the content to the local file system anyway, so if we download them ourselves it is equivalent. Actually, doing it ourselves has a lot of benefits. The VM likes to cache urls in a cache you can't flush, so redeploy tends to break. Also File is just easier to use than URL. -dain
Re: GERONIMO-1526
On Aug 21, 2006, at 1:31 PM, Dain Sundstrom wrote: Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important. From the deployers perspective, they just need to get added to the classpath... so there probably is not much difference there... I think using URLs instead of files, is going to be very difficult. We had tons of problems dealing with paths containing spaces and urls. IIRC we had to encode and decode URLs all the time. Also, some deployers need to scan the directories. For example, the RAR deployer needs to add all jar files in the archive/ directory to the class path. In Jee5 ear files we need to scan for all nested modules. Ya maybe... I was just thinking about deploying from things other than files, like an http:// address or nested jar, or some other custom protocol. Using URL allows flexibility by abstraction... where using File binds you to files, since we have no way to augment them. I wish that java.io.File was a more extensible abstraction... like VFS FileObject or something... --jason
Re: GERONIMO-1526
Thanks. I have a few questions/issues...
Why the separation between resources and classes. Don't we need to
add both to the class loader anyway? I'm curious when this
differentiation is important.
I think using URLs instead of files, is going to be very difficult.
We had tons of problems dealing with paths containing spaces and
urls. IIRC we had to encode and decode URLs all the time. Also,
some deployers need to scan the directories. For example, the RAR
deployer needs to add all jar files in the archive/directory to the
class path. In Jee5 ear files we need to scan for all nested modules.
I find the method name isBinary confusing. Can we use something like
isArchived instead?
-dain
On Aug 21, 2006, at 1:16 PM, Sachin Patel wrote:
Doh, sorry, guess some javadoc would help :)... So basically the
idea is to be able to represent a deployable object, that can be
either a jar, or some custom structure specific to a given IDE/
build environemnt.
public interface DeployableModule {
/**
* uri of the module, foo.ear, if a nested module then foo.ear/
foo.war
*/
String getURI();
/**
* root url of the module, if isBinary then would return absolute
URL of the archive, otherwise
* the root folder of the module.
* @return
*/
URL getRoot();
/**
* returns all the URLs that provide content to this module
(non .class files) if isBinary then this would return
* empty array
* @return
*/
URL[] getResourceFolders();
/**
* returns all the URLs that contai, if isBinary then this would
return an empty array
* @return
*/
URL[] getClassesFolders();
/**
* Returns true if this is a binary module (JarFile)
*/
boolean isBinary();
/**
* returns nested modules, so for an ear file, would return all
its contained modules, for a web module, entries web-inf/lib entries
*/
DeployableModule[] getModules();
}
On Aug 21, 2006, at 3:57 PM, Dain Sundstrom wrote:
Some java docs would help me understand what these methods are
supposed to do.
-dain
On Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:
For the following JIRA, where all the module builders assume a
jar file, what if we change all methods that take a JarFile to
something like the following?
public interface IDeployableModule {
public String getURI();
public File getRoot();
public File[] getResourceFolders();
public File[] getClassesFolders();
public boolean isBinary();
public IDeployableModule[] getChildModules();
}
-sachin
-sachin
Re: GERONIMO-1526
FYI @return with no args is not a valid javadoc tag. :-PAlso, not sure that getURI() should return a string... maybe getURI() is not the right name, I'd expect a method like that to return a URI instance. But overall, I think that if this interface will allow IDE plugins the intel they need then this is positive direction.--jasonOn Aug 21, 2006, at 1:16 PM, Sachin Patel wrote:Doh, sorry, guess some javadoc would help :)... So basically the idea is to be able to represent a deployable object, that can be either a jar, or some custom structure specific to a given IDE/build environemnt.public interface DeployableModule { /** * uri of the module, foo.ear, if a nested module then foo.ear/foo.war */ String getURI(); /** * root url of the module, if isBinary then would return absolute URL of the archive, otherwise * the root folder of the module. * @return */ URL getRoot(); /** * returns all the URLs that provide content to this module (non .class files) if isBinary then this would return * empty array * @return */ URL[] getResourceFolders(); /** * returns all the URLs that contai, if isBinary then this would return an empty array * @return */ URL[] getClassesFolders(); /** * Returns true if this is a binary module (JarFile) */ boolean isBinary(); /** * returns nested modules, so for an ear file, would return all its contained modules, for a web module, entries web-inf/lib entries */ DeployableModule[] getModules();}On Aug 21, 2006, at 3:57 PM, Dain Sundstrom wrote:Some java docs would help me understand what these methods are supposed to do.-dainOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote: For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin -sachin
Re: GERONIMO-1526
Doh, sorry, guess some javadoc would help :)... So basically the idea is to be able to represent a deployable object, that can be either a jar, or some custom structure specific to a given IDE/build environemnt.public interface DeployableModule { /** * uri of the module, foo.ear, if a nested module then foo.ear/foo.war */ String getURI(); /** * root url of the module, if isBinary then would return absolute URL of the archive, otherwise * the root folder of the module. * @return */ URL getRoot(); /** * returns all the URLs that provide content to this module (non .class files) if isBinary then this would return * empty array * @return */ URL[] getResourceFolders(); /** * returns all the URLs that contai, if isBinary then this would return an empty array * @return */ URL[] getClassesFolders(); /** * Returns true if this is a binary module (JarFile) */ boolean isBinary(); /** * returns nested modules, so for an ear file, would return all its contained modules, for a web module, entries web-inf/lib entries */ DeployableModule[] getModules();}On Aug 21, 2006, at 3:57 PM, Dain Sundstrom wrote:Some java docs would help me understand what these methods are supposed to do.-dainOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote: For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin -sachin
Re: GERONIMO-1526
Some java docs would help me understand what these methods are
supposed to do.
-dain
On Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:
For the following JIRA, where all the module builders assume a jar
file, what if we change all methods that take a JarFile to
something like the following?
public interface IDeployableModule {
public String getURI();
public File getRoot();
public File[] getResourceFolders();
public File[] getClassesFolders();
public boolean isBinary();
public IDeployableModule[] getChildModules();
}
-sachin
Re: GERONIMO-1526
I'd also drop the public modifier for methods... its redundant ;-)--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin
Re: GERONIMO-1526
On Aug 21, 2006, at 2:18 PM, Jason Dillon wrote:Minus the "I" prefix... seems okay. What about using URLs instead of Files?Yep, agree.--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin -sachin
Re: GERONIMO-1526
Minus the "I" prefix... seems okay. What about using URLs instead of Files?--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin
