felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Roadmap
Date Mon, 21 May 2007 18:12:50 GMT
Carlos Sanchez wrote:
> On 5/21/07, Richard S. Hall <heavy@ungoverned.org> wrote:
>> Personally, I would love for us to have "groupId=org.apache.felix" and
>> "artifactId=<subproject-name>", but the reason why we didn't follow this
>> approach in the first place was that we wanted our artifacts to be named
>> "org.apache.felix.subproject-version.jar", so we had to set the
>> artifactId to the full package name to get this result.
>
> the question is where do you need to have that name?
> you shouldn't care how is stored in the repository, do you want it
> when packaged by the assembly plugin or any other plugin?

Not everyone deals with these artifacts through a Maven repository, so 
their name is not hidden. For example, the framework gets distributed 
with several bundle JAR files, which will be part of our release package.

I don't care how it is stored in the repository. The issue I have is 
that the generated artifact in target/ has a name...I don't want to 
manually have to change the name after doing "mvn clean 
install"...however, it is probably better if the names can be the same, 
since it would avoid confusion since it would be more difficult to tell 
whether a JAR file downloaded from a Maven repo was the same as a JAR 
file we were re-distributing.

>> You are not saying that you are changing the default behavior of using
>> artifactId as the artifact name, right? You are saying we should modify
>> our plugin to use whatever artifact name we want, correct? If so, I
>> guess that works for me, we just need to know what we need to do to get
>> our plugin doing the rename.
>
>
> I say that you shouldn't be using (ideally)
> groupId org.apache.felix
> artifactId: org.apache.felix.y
>
> let me know in what cases you need the final jar to have
> org.apache.felix.y name and I'll work on getting whatever plugins
> needed to rename it so you can use "y" as artifactId

Perhaps I don't know the proper Maven terminology, but I am talking 
about the resulting artifact in the target/ directory. However, as I 
said above, it is probably best if the two (i.e., the target JAR and the 
repo JAR) match, to avoid confusion.

>> Still, I am not altogether clear how this issue relates to our
>> discussion of what the artifactId for our plugin should be. Are these
>> two related?
>
>
> right, it's not related to plugin autodiscovery

Good. So, do you recommend that we use maven-bundle-plugin for the 
artifactId of the bundle plugin?

-> richard

>
>>
>> -> richard
>>
>> >
>> >
>> > 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
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> >
>> >>
>> >
>> >
>>
>
>

Mime
View raw message