On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Alin Dreghiciu wrote: > About the naming convention as I recall this is a convention in order to > shorten the command line that you will have to to type when launching a > maven plugin. And by naming convention maven can do the magic of > calling for > example maven-assembly-plugin when you type mvn assembly:assembly. If that is the reason, then I guess it makes sense. However, it seems that Maven could have accomplished this just as easily by allowing us to specify the "alias" somewhere in the myriad of XML, rather than imposing a naming convention... > I also have another question (which maybe was already discussed but > I'm not > aware of): Can't the bundle plugin get a life of it's own as many of the > other maven standard plugins or at least to be released independently > from > felix? My main "problem" is that I want to use the latest version of the > plugin but this wil mean to depend on the apache snapshots repository, > and > when you depend on this repo maven will bring in a lot of other snapshots > versions of the plugin. I am not sure I understand. The plugin does have a life of its own. The fact that you want to use the latest version means that you have to get it from the SNAPSHOT repo...that is the way that it works. On the other hand, if you want to use the latest 'released' version, then you can get it too and this won't be in the SNAPSHOT repo. The issue you are having has nothing to do with the plugin and whether or not it has a life of its own, it has to do with how Maven handles the SNAPSHOT repo. I think the question you really mean to ask is, is there some way I can scope my dependencies in the SNAPSHOT repo so that I only get what I want from it rather than everything?
You are right about the the core problem: how maven handles the snapshot repo in the context of plugins. But if the bundle plugin it will not be tight to the release cycle of felix I suppose that it can be released more frequently, fact that will allow me to keep the dependency on the released version and not the snapshot one. Bassicaly this is what I ment by "a life of it's own" Regards, Alin Dreghiciu -> richard
> > Regards, > Alin Dreghiciu > > On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote: >> >> Tim Moloney wrote: >> > I agree with the proposed roadmap. My only comment is on the name of >> > the plugin. bundleplugin doesn't follow the Maven convention of >> > maven-foo-plugin or foo-maven-plugin. >> >> Is there some reason for this convention? It ends up violating our own >> convention of naming generated artifacts after their own package root in >> our repo (e.g., org.apache.felix.bundleplugin-0.9.0.jar). >> >> If the general view is that we should follow this convention (which I >> wasn't aware of), then I will change it back. >> >> -> richard >> >> > >> > >> > Richard S. Hall wrote: >> >> Richard S. Hall wrote: >> >>> Carlos Sanchez wrote: >> >>>> A release as TLP is very important as it's going to be available in >> >>>> the main maven repository instead of the incubating one which other >> >>>> projects can't use to make releases. >> >>>> I'd love to see the release of the bundle plugin to use it in the >> >>>> Maven project. >> >>> >> >>> The maven-bundle-plugin would be included in the release since it is >> >>> used by the framework and the shell bundles. >> >>> >> >>> Actually, I have been wanting to 1) change the plugin to be a >> >>> top-level subproject in the svn repo, which would also mean 2) >> >>> changing its package (from >> >>> org.apache.felix.framework.tools.maven2.bundleplugin to >> >>> org.apache.felix.bundleplugin), and I would also 3) like to change >> >>> its name from maven-bundle-plugin to perhaps just bundleplugin. >> >> >> >> Ok, rather than just say that I want to do the above, I decided to >> >> just go ahead and do it. I have moved maven-bundle-plugin to the >> >> trunk directory, renamed it to bundleplugin (and artifactId to >> >> org.apache.felix.bundleplugin), changed its package structure, and >> >> updated all POM files that used the plugin to refer to the new name >> >> (thanks to Karl for a shell script to do that). I rebuilt everything >> >> from scratch with an empty repo and it build for me...and I made Karl >> >> try it too. >> >> >> >> After doing "svn update", you will need to delete the directory >> >> 'tools/maven2/maven-bundle-plugin'... >> >> >> >>> This will be part of the previous discussion that we had about >> >>> reorganizing the svn repo to have all subprojects have their own >> >>> top-level directory in the trunk, with related modules of the >> >>> sub-project under the sub-project directory rather than in the >> >>> trunk. I plan to start making this mods to the repo shortly. >> >> >> >> Just like the above, Karl and I have started to reorganize the repo. >> >> The eventadmin project was refactored and I will do iPOJO next. Once >> >> we get UPnP and MOSGi moved to the new approach, we should have a >> >> manageable trunk directory! :-) >> >> >> >> -> richard >> >> >> >>> >> >>> -> richard >> >>> >> >>>> >> >>>> my 0.02 >> >>>> >> >>>> On 5/20/07, Karl Pauls <[EMAIL PROTECTED]> wrote: >> >>>>> Dear Felix Community, >> >>>>> >> >>>>> in order to follow-up on recent discussions - and our new >> status as >> a >> >>>>> TLP - I'd like to get a roadmap towards a new release going. >> Let me >> >>>>> try to get a few thoughts across and see what the general >> reactions >> >>>>> are :-) >> >>>>> >> >>>>> Looking back at recent comments and events I believe it would be >> >>>>> beneficial to get a new (and first) official release out of the >> door >> >>>>> as soon as possible. That would make it more clear where we are at >> >>>>> the >> >>>>> moment and give Felix users something to build trust upon. >> >>>>> >> >>>>> Personally, I'd prefer to get a "core release" out quickly. I know >> >>>>> that a lot of the subprojects are eager to get something out >> but we >> >>>>> need to discuss how to handle those releases and I don't want to >> >>>>> delay >> >>>>> the core release because of that. >> >>>>> >> >>>>> That said, taking the last release into account I guess, it >> would be >> >>>>> fairly easy to get the involved parts into shape and released >> within >> >>>>> the next month or two (namely, main, framework, plugin, shell, >> >>>>> shell.tui, bundlerepository, and org.osgi.core). >> >>>>> >> >>>>> Richard tells me that he has still some stuff to commit to >> clean-up >> >>>>> the required bundle functionality, wants to address FELIX-203, >> and I >> >>>>> do have two small patches for the extension bundle stuff. >> >>>>> >> >>>>> Other then that, we would need to remove the incubator references, >> >>>>> create proper NOTICE files, figure out a changelog, and tackle >> a few >> >>>>> questions namely, >> >>>>> >> >>>>> 1) Should it be yet another tarball release or does somebody >> >>>>> volunteer to >> >>>>> get our installer up and running again? >> >>>>> >> >>>>> 2) Is this going to be our 1.0 release? >> >>>>> >> >>>>> In regard to 2), I'm leaning towards a 1.0 release to emphasize >> >>>>> our status as a >> >>>>> graduated project and the fact that the core Felix technology is >> >>>>> stable >> >>>>> and usable now. I do not think it is necessary to tie the 1.0 >> >>>>> release to >> >>>>> complete spec compliance, since being below 1.0 generally has a >> "not >> >>>>> quite ready" stigma attached to it, which is not the case. Our >> >>>>> goal is >> >>>>> spec compliance and we will have to be clear in which areas we are >> >>>>> not >> >>>>> yet compliant, but Felix is definitely far enough along to be >> >>>>> considered >> >>>>> stable and a 1.0 release. However, if there are strong feelings to >> >>>>> the >> >>>>> contrary, my opinion could be changed. >> >>>>> >> >>>>> What do you all think? >> >>>>> >> >>>>> regards, >> >>>>> >> >>>>> Karl >> >>>>> >> >>>>> -- >> >>>>> Karl Pauls >> >>>>> [EMAIL PROTECTED] >> >>>>> >> >>>> >> >>>> >> >> >> > >> >
