felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Sanchez" <car...@apache.org>
Subject Re: Roadmap
Date Mon, 21 May 2007 15:39:46 GMT
On 5/21/07, Richard S. Hall <heavy@ungoverned.org> 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...

This only affects when using the command line, which I guess it's
going to be the minimal portion of the time. If you configure it as
part of the standard lifecycle you wouldn't need to worry (eg. calling
mvn package)

>
> > 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 can define the version of plugins you want in the pluginManagement
section. The felix parent pom already does this. If not maven will
look for the latest version in all defined repos including snapshots.
It's likely to be improved in 2.1 but it's still a good idea to lock
down the versions you want.

>
> -> richard
> >
> > Regards,
> > Alin Dreghiciu
> >
> > On 5/21/07, Richard S. Hall <heavy@ungoverned.org> 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 <karlpauls@gmail.com> 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
> >> >>>>> karlpauls@gmail.com
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >
> >>
> >
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

Mime
View raw message