On 16/08/07, Alin Dreghiciu <[EMAIL PROTECTED]> wrote:
firstly thanks to Alin for answering a lot of this on my behalf!
On 8/15/07, Ingo Meyer <[EMAIL PROTECTED]> wrote:
> >
> > yes, i found that (of course :-)
> >
> > So I guess that these poms were created when i run pax-create-project?
> > And I guess also that they never get changed anymore so I can make my
> > personal changes?
> >
>
yes - Pax Construct 0.1.6 has the following layout:
myProject
\__poms default configuration
\__bundle_1 OSGi bundles, can be:
\__bundle_2 wrapped,
\__...... imported,
\__bundle_N or compiled
where poms contains the default settings for imported, wrapped and compiled
bundles
once generated, these files are yours to edit :)
yep.
>
> Why you always assume an internal package, even when it does not exists?
> >
>
> Is a good practice to place classes that should not get exported in a
> separate directory. And as long as I know is a common practice to name that
> directory internal.
>
yes - it's just a reasonable default... if the package doesn't exist, it
won't cause a problem
the "compiled" defaults in 0.1.6 assume that each bundle provides a distinct
package
with a public and private namespace:
Bundle A provides org.foo.api
Bundle B provides org.foo.bar
Bundle C provides org.foo.zzz
you are free to use a different style, for example:
Bundle A provides org.foo
Bundle B provides org.foo.bar
etc...
but you'll need to change the defaults - they're really just there to get
people started
and like all default settings, you just hope they match with people's
expectations
please feel free to suggest where the defaults could be improved
What is the reason for the Bundle-SymbolicName like:
> > -<Bundle-SymbolicName>$(replace;${bundle.package}_${project.artifactId
> > };-;_)</Bundle-SymbolicName>-
> >
>
> Well, not sure. We must wait for Stuart on this.
>
it is generally common for the bundle symbolic name to relate to the package
it
provides (hence the default that a given bundle relates to a particular
package)
the reason it's not the groupId is because this may not relate to the
contents
of that bundle - the bundle's artifactId (ie. it's name from
pax-create-bundle)
is used to ensure uniqueness where two bundles may share a package, eg:
Bundle A provides org.foo (the api)
Bundle B provides org.foo.internal (an implementation)
FYI, to do this you'd use:
pax-create-bundle -p org.foo -n A -- -Dactivator=false
pax-create-bundle -p org.foo -n B -- -Dinterface=false
finally, the reason for the replace of '-' to '_' is because the OSGi spec
doesn't
allow dashes in the symbolic name, whereas maven allows them in artifactId
But anyhow is a default so feel free to change it your way.
> My guess is that the naming was done this way to be able to distinct
> between more artifacts having the same artifact id but in different groups.
> just a guess.
>
exactly
For me the artifactId is contained in the bundle package. This leads to
> > something like:
> > org.xxx.dataaccess.proxy.http.dao_dataaccess.proxy.http.dao
> > Really ugly in my opinion. But I think you all are using the groupId
> > different then me.
> > Is there any good spec about these naming?
> >
>
this is a common question - some maven based projects use the following:
groupId org.foo
artifactId bar
and other projects use:
groupId org.foo
artifactId org.foo.bar
benefit of the last approach, is a better name for the final artifact - but
as you
say. this would lead to a longer symbolic name when using the Pax Construct
defaults
Doesn't pop up imediatelly but a good one for me at least is ${
> project.groupId}.${project.artifactId }
>
> Thanks for answering all my (stupid) questions...
> >
>
> There is no stupid question :)
>
very true - these are all good questions!
I'm working on a partial rewrite of Pax-Construct based on all the feedback
- basically aiming to really simplify the structure, improve defaults, etc.
-
which is possible because some of the things it used to do are now being
incorporated in the underlying tools, like the bundle-plugin
if you want anything (and I really mean anything) changed, please open
an issue over at JIRA: http://issues.ops4j.org/jira/browse/PAXCONSTRUCT
similarly, there's a wiki page with basic usage:
http://wiki.ops4j.org/confluence/display/ops4j/Pax+Construct
(and again, Pax Construct 2.x will provide much better examples!)
also, if you want to help in the new version let me know because it's
very easy to start participating (everyone in OPS4J should get commit
rights by default)
Ingo
> >
> > Am 15.08.2007 um 18:23 schrieb Alin Dreghiciu:
> >
> > in the created project you will find a directory named poms. then look
> > in the directory named compiled. The pom from there is the parent for
> > your bundle pom so everything is inherited.
> > If you wanna make the changes you exemplified for all bundles make the
> > change here. Otherwise just copy the plugin section for bundle plugin to
> > your bundle pom and change it the way you like.
> >
> >
> > Cheers,
> > Alin
> >
> > On 8/15/07, Ingo Meyer < [EMAIL PROTECTED] > wrote:
> > >
> > > Hi,
> > >
> > > just a beginners question but I don't find any docs about it.
> > > Where can I configure the Bundles Im-/Export and Internal Package and
> > > Activator in the maven-pax-plugin.
> > > I found the detail.bnd and deleted the Activator entry and I dont
> > > have a Activator in my manifest, fine.
> > > But i always have Private-Package setted.
> > >
> > > Another thing is the Bundle-SymbolicName. I don't see where it is
> > > coming from, it is not my groupId.artifactId (and it should not)
> > > but it should be <groupId of parent>.artifactId, or not?
> > > Now it is something like <groupId of parent>.artifactId.artifactId
> > >
> > > Can someone clarify me?
> > > Any further information needed?
> > >
> > > Thanks for help
> > > Ingo Meyer
> > >
> > >
> > > ______________________________ _________________
> > > general mailing list
> > > general@lists.ops4j.org
> > > http://lists.ops4j.org/mailman/listinfo/general
> > >
> >
> > _______________________________________________
> > general mailing list
> > general@lists.ops4j.org
> > http://lists.ops4j.org/mailman
> > <http://lists.ops4j.org/mailman/listinfo/general>/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general>
> >
> >
> >
> >
> > ______________________________ _________________
> > general mailing list
> > general@lists.ops4j.org
> > http://lists.ops4j.org/mailman<http://lists.ops4j.org/mailman/listinfo/general>
> > /listinfo/general <http://lists.ops4j.org/mailman/listinfo/general>
> >
> >
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
>
--
Cheers, Stuart
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
