Re: [jci] out of the sandbox
On 18.03.2007, at 06:51, Mario Ivankovits wrote: Hi! I had a quick look at the filesystem alteration monitor module - looks like could be useful component for people outside of JCI. I was thinking the same. But atm I would rather just get it releases. That probably means as part of JCI. Since it's a multi project there is big difference to a separate component anyway. I know of a couple of projects just using that jar. Yea, in the long term we discussed to replace the VFS's one with this implementation, though, if it is its own component with an abstract FS implementation it would be fine too. Under the hood it is already abstracted. The interface is not exposed though. Happy to have a chat about the details/problems I am seeing with it. commons-io might be a good place then. Big -1! Let's try not to bloat components like IO and LANG too much. IMO it deserves to be its own (sub) component. People are already complaining about the jar sizes of IO and LANG. (although I then point them to http://mojo.codehaus.org/minijar-maven-plugin/ index.html then :-P ) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 3/17/07, Torsten Curdt [EMAIL PROTECTED] wrote: I'd like to bring this well before an actual vote. At the moment I am still in the middle of documenting and fixing up JCI for a first 1.0 release. I hope to be able to provide a first RC1 at the end of next week ...latest the week after. There are a few things about JCI that are worth talking about. 1) Community Frankly speaking there still is no big developer community. There are contributors - but so far I am the only one committing. Still the project is integral part and heavily used by well known projects like Cocoon and Drools (plus more of course). Now both communities are eagerly waiting for a release (as this also blocks their release process). IMO community should not be too much of a concern. If there is a bug and I don't - I know they will dig into it. JCI might have well more people behind it than other components we have. Oh ...and testcase coverage is good :) So question is whether it is OK to move JCI out of the sandbox - soon. Sounds good to me. A component being alive and getting close to being release ready is IMO good enough criteria. To the outside world I don't think theres much difference when there hasn't been a release - and with now having a dormant area we also have a place to put things that graduate and then do nothing. 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. What are the different modules for - can you give a brief description? 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. The homepage is just about as minimalist as it gets - at least a couple of paragraphs giving a flavour would be nice and maybe the odd example. http://jakarta.apache.org/commons/sandbox/jci/ 3) groupId I would like to use the proper maven2 groupId naming scheme for JCI. +1 Niall Thoughts? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
Seems like a bad idea for a Commons component: * Potential confusion due to version numbers of modules moving independently etc.. * Its unlikely that releasing one module is significantly easier than releasing all. * Its likely that even though after a given quantum of time major changes are in one module (hence the temptation to release separately), there will probably be little changes elsewhere that are good to push out anyway * Data points around us -- even larger multi-project m2 builds like Shale (Struts too, I believe) release all bits together (yes, not all reasons there make sense here, but ... data points). Hm... well I am not religious about this. But re-releasing the core just because a bug in a compiler implementation does not really make much sense to me. But basically that's why I brought this up beforehand ...to check with you guys. How about: * A little guide? Tiny code snippets? Coming! There is already an example sub project featuring a (more or less) javac compatible command line interface to jci and a serverpages servlet. Still more to come. And of course that needs to be linked from the site. * package.html files? Coming! cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. Attributes had 2 jars - and a build that was irritating because of it. ie) you didn't just go 'lah! build' in the standard way. Jelly has a bajillion jars. I assume it's an m1 multiproject. BeanUtils has a couple of jars; but the optional one is more of a thick-child-project. I seem to recall it being a pain to build. So not the first. Well ...but the first one with a maven2 build - no? :) Rahul's point on keeping versions in sync is well made. 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. http://jakarta.apache.org/commons/sandbox/jci/ Seems pretty bad - no information about the N different subcomponents, and the dependency page claims there are no deps (really?). I guess you've not written the site itself yet? :) Well, the problem is that the sub project are basically just a few classes. Having a complete site for every sub-project feels more confusing to me than aggregating it on the main site. BUT as you can see aggregation does not work for all reports and e.g. the dependencies are listed for the parent pom - not the core or the sub projects. And therefor are empty. I can put a site online with all the sub projects. And then you guys can let me know if you prefer that. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. What are the different modules for - can you give a brief description? JCI is basically split up into o fam - the filesystem alteration monitor o core - core interfaces and classes o compiler implementations for - eclipse - janinio - groovy - javac - rhino - jsr199 o examples - some examples showing how to use jci cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 3/17/07, Torsten Curdt [EMAIL PROTECTED] wrote: 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. What are the different modules for - can you give a brief description? JCI is basically split up into o fam - the filesystem alteration monitor o core - core interfaces and classes o compiler implementations for - eclipse - janinio - groovy - javac - rhino - jsr199 o examples - some examples showing how to use jci I had a quick look at the filesystem alteration monitor module - looks like could be useful component for people outside of JCI. If you're planning on releasing modules independantly anyway, maybe it should be a commons component in its own right (or perhaps part of Commons IO?). Niall cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
Hi! I had a quick look at the filesystem alteration monitor module - looks like could be useful component for people outside of JCI. Yea, in the long term we discussed to replace the VFS's one with this implementation, though, if it is its own component with an abstract FS implementation it would be fine too. commons-io might be a good place then. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: I'd like to bring this well before an actual vote. At the moment I am still in the middle of documenting and fixing up JCI for a first 1.0 release. I hope to be able to provide a first RC1 at the end of next week ...latest the week after. There are a few things about JCI that are worth talking about. snip-community/ 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. snap/ Seems like a bad idea for a Commons component: * Potential confusion due to version numbers of modules moving independently etc.. * Its unlikely that releasing one module is significantly easier than releasing all. * Its likely that even though after a given quantum of time major changes are in one module (hence the temptation to release separately), there will probably be little changes elsewhere that are good to push out anyway * Data points around us -- even larger multi-project m2 builds like Shale (Struts too, I believe) release all bits together (yes, not all reasons there make sense here, but ... data points). 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. http://jakarta.apache.org/commons/sandbox/jci/ snip/ How about: * A little guide? Tiny code snippets? * package.html files? 3) groupId I would like to use the proper maven2 groupId naming scheme for JCI. snap/ Sure. -Rahul Thoughts? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: I'd like to bring this well before an actual vote. At the moment I am still in the middle of documenting and fixing up JCI for a first 1.0 release. I hope to be able to provide a first RC1 at the end of next week ...latest the week after. There are a few things about JCI that are worth talking about. 1) Community Frankly speaking there still is no big developer community. There are contributors - but so far I am the only one committing. Still the project is integral part and heavily used by well known projects like Cocoon and Drools (plus more of course). Now both communities are eagerly waiting for a release (as this also blocks their release process). IMO community should not be too much of a concern. If there is a bug and I don't - I know they will dig into it. JCI might have well more people behind it than other components we have. Oh ...and testcase coverage is good :) So question is whether it is OK to move JCI out of the sandbox - soon. Given the number of components we have in Commons that have 0..1 committers actively working on them, I think the '3 committers' rule has grown old and unnecessary. The worst that happens is we have a release out there that is being used and we end up with another component that needs releases etc. My view - let's deal with that when it happens rather than stunting JCI now. 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. Attributes had 2 jars - and a build that was irritating because of it. ie) you didn't just go 'lah! build' in the standard way. Jelly has a bajillion jars. I assume it's an m1 multiproject. BeanUtils has a couple of jars; but the optional one is more of a thick-child-project. I seem to recall it being a pain to build. So not the first. Rahul's point on keeping versions in sync is well made. 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. http://jakarta.apache.org/commons/sandbox/jci/ Seems pretty bad - no information about the N different subcomponents, and the dependency page claims there are no deps (really?). I guess you've not written the site itself yet? :) 3) groupId I would like to use the proper maven2 groupId naming scheme for JCI. I think this is a given, based on other threads. New components use org.apache.commons. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
