You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/08/01 21:04:59 UTC
Re: Source re-structuring
I have just seen, thx to a user on the mailing list, that
the maven plugin depends on servicemix-core.
To the mentioned steps won't even work when building from a clean computer.
Afaik, currently, you will need to build servicemix-core and its
dependencies
one by one, to be allow to build the maven plugin, and then the components.
Maybe we could use maven profiles to ease that, but I really hope
the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
in 2.0.5 asap.
Restructuring would help a bit, in that it would allow to build the core
container and its dependencies in one run.
The other way would be to split to jbi plugin into two different plugins,
one that would contain the maven packaging, and one that would
contain the ant tasks and other goals, like jbi:servicemix.
Any opinion on what to do ?
On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Not really.
> There is a bug in maven which cause maven plugins with extension to not
> being
> used when build in the current build. Not sure I'm very clear, here.
> The problem happen when you build from a clean machine.
> You can not do
> mvn install
> from the root and expect everything to work.
> This works for simple maven plugins, but not for plugins using
> "extensions" :(
> You need to do
> mvn -N install
> cd tooling
> mvn install
> cd ..
> mvn install
>
> At least, it is my understanding on how maven currently works.
>
>
> On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> >
> > One note on the plugin - with the re-org the build order would succeed
> > if
> > you built core first - the tooling - then everything else since nothing
> > in
> > core requires the plugin
> >
> > P
> >
> > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > >
> > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > >
> > > > I put together a basic plan (with some help from Guillaume), here
> > > >
> > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > >
> > > > The purpose of the new structure it two allow cleaner separation
> > > between:
> > > >
> > > > 1/ The JBI Container
> > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > 3/ Platform specific packaging projects
> > > > 4/ Archetypes
> > > > 5/ Tooling
> > > > 6/ Sampels
> > > >
> > > > By categorizing the source it should become easier to read and
> > therefore
> > > > identifying what SE/BC's/SL's are available should become more
> > > > obvious, as
> > > > well as cleanly showing what is required for core Container
> > > functionality.
> > > >
> > > > There are a couple of ommissions - first rather than one assembly
> > > > (currently
> > > > apache-servicemix project) I would like to add a root directories
> > called
> > > > assemblies and then create a few packaging (as previously mentioned)
> > > >
> > > > ie.
> > > >
> > > > assemblies
> > > > \ core-only
> > > > \ core-and-components
> > > > etc.
> > >
> > >
> > > +1 to this reorg
> > > The question is wether we will release everything at the same time or
> > not.
> > > Currently, the problem is that we need to build the maven plugin in a
> > > first
> > > step,
> > > else maven will not pick it while building the whole source tree.
> > > We could avoid that if we could release the plugin, then use it to
> > build
> > > the
> > > source tree
> > > (as done in Geronimo). But the maven plugin needs the core container
> > > before
> > > :(
> > >
> > > The other is the servicemix-components package, there are two ways to
> > go
> > > > here:
> > > >
> > > > 1/ Break up the components into different service engines
> > >
> > >
> > > Or break the components jar into different jars.
> > > This would allow to replace all optional dependencies by non optional
> > > dependencies
> > > and the maven plugin could be used to generate SU and bundle all the
> > > necessary dependencies.
> > >
> > > 2/ Turn the servicemix-components jar into an SE, add a dependencies
> > on
> > > the
> > > > servicemix-lwcontainer and then change all the libs to optional
> > false
> > > >
> > > > I'm not keen on the first way because I think the conversion to real
> > > SE's
> > > > will take some time and should be given space to make sure we are
> > able
> > > to
> > > > address things like WSDL for services etc.
> > > >
> > > > In the second option we end up with a large SE though I believe it
> > will
> > > > provide all the functionality, I was thinknig that this would be a
> > > > special
> > > > packaging - ie. your can download just that big SE separate from the
> >
> > > other
> > > > assemblies.
> > >
> > >
> > > Yeah, maybe. We need to rewrite the examples to be less focused on
> > > servicemix-lwcontainer.
> > >
> > > I would like to try and get a discussion going on this since once this
> > is
> > > > out of the way we could then look to the work invovled in converting
> > > some
> > > > of
> > > > the lw-container service engines into more complete JBI Service
> > Engines
> > > > (using the service-engine architype as a basis) and also work on
> > puting
> > > > more
> > > > WSDL in place for those services :)
> > >
> > >
> > > +1
> > >
> > > P
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
Re: Source re-structuring
Posted by Guillaume Nodet <gn...@gmail.com>.
I have just checked in a fix to the root pom to exclude this dependency
from xfire-all.
On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> As a workaround, you can copy the jar from
> http://repo.mergere.com/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> to
> ~/.m2/java/xml/jsr173/1.0
>
> I will look at the problem now.
>
>
> On 8/1/06, Philip Dodds <ph...@gmail.com> wrote:
> >
> > Great! Did you have any luck on the jsr171 dependency?
> >
> > P
> >
> > On 8/1/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > >
> > > I have just added some profiles to the build system.
> > > They can be activated using
> > > mvn -Dprofile=name
> > >
> > > where name can be
> > > container => servicemix-services, servicemix-jbi, servicemix-core
> > > tooling => tooling
> > > components => beanflow, components, common, soap, bpe, ...
> > > assembly => samples, apache-servicemix
> > > step1 => container + tooling
> > > step2 => components + assembly
> > >
> > > The default profile will build everything.
> > >
> > > This way, we should be able to build everything on a clean host using
> > > mvn -Dprofile=step1
> > > mvn -Dprofile=step2
> > >
> > >
> > >
> > >
> > > On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > >
> > > > Right.
> > > > I will try maven profiles and see if I can find a way to sort this
> > out.
> > > >
> > > >
> > > > On 8/1/06, Philip Dodds <philip.dodds@gmail.com > wrote:
> > > > >
> > > > > I have thought about splitting the plugin - the only issue i could
> > see
> > > > > is
> > > > > having to add the other plugin to projects to run them under
> > > servicemix
> > > > > or
> > > > > to deploy them. Though splitting would still require use of
> > profiles
> > > to
> > > > > have a core/tooling and everything else profile? Unless we create
> > two
> > > > > tooling directories?
> > > > >
> > > > > Since we have talked about not producing too much change pre-3.0,
> > I
> > > > > would
> > > > > push for profiles and then lets try and see when Maven can fix the
> > > issue
> > > > > :)
> > > > >
> > > > > P
> > > > >
> > > > > On 8/1/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > >
> > > > > > I have just seen, thx to a user on the mailing list, that
> > > > > > the maven plugin depends on servicemix-core.
> > > > > > To the mentioned steps won't even work when building from a
> > clean
> > > > > > computer.
> > > > > > Afaik, currently, you will need to build servicemix-core and its
> >
> > > > > > dependencies
> > > > > > one by one, to be allow to build the maven plugin, and then the
> > > > > > components.
> > > > > >
> > > > > > Maybe we could use maven profiles to ease that, but I really
> > hope
> > > > > > the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> > > > > > in 2.0.5 asap.
> > > > > > Restructuring would help a bit, in that it would allow to build
> > the
> > > > > core
> > > > > > container and its dependencies in one run.
> > > > > >
> > > > > > The other way would be to split to jbi plugin into two different
> > > > > plugins,
> > > > > > one that would contain the maven packaging, and one that would
> > > > > > contain the ant tasks and other goals, like jbi:servicemix.
> > > > > >
> > > > > > Any opinion on what to do ?
> > > > > >
> > > > > > On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > > > > >
> > > > > > > Not really.
> > > > > > > There is a bug in maven which cause maven plugins with
> > extension
> > > to
> > > > > not
> > > > > > > being
> > > > > > > used when build in the current build. Not sure I'm very
> > clear,
> > > > > here.
> > > > > > > The problem happen when you build from a clean machine.
> > > > > > > You can not do
> > > > > > > mvn install
> > > > > > > from the root and expect everything to work.
> > > > > > > This works for simple maven plugins, but not for plugins using
> >
> > > > > > > "extensions" :(
> > > > > > > You need to do
> > > > > > > mvn -N install
> > > > > > > cd tooling
> > > > > > > mvn install
> > > > > > > cd ..
> > > > > > > mvn install
> > > > > > >
> > > > > > > At least, it is my understanding on how maven currently works.
> > > > > > >
> > > > > > >
> > > > > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > One note on the plugin - with the re-org the build order
> > would
> > > > > succeed
> > > > > > > > if
> > > > > > > > you built core first - the tooling - then everything else
> > since
> > > > > > nothing
> > > > > > > > in
> > > > > > > > core requires the plugin
> > > > > > > >
> > > > > > > > P
> > > > > > > >
> > > > > > > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 7/28/06, Philip Dodds < philip.dodds@gmail.com > wrote:
> > > > > > > > > >
> > > > > > > > > > I put together a basic plan (with some help from
> > Guillaume),
> > > > > here
> > > > > > > > > >
> > > > > > > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > > > > > > >
> > > > > > > > > > The purpose of the new structure it two allow cleaner
> > > > > separation
> > > > > > > > > between:
> > > > > > > > > >
> > > > > > > > > > 1/ The JBI Container
> > > > > > > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > > > > > > 3/ Platform specific packaging projects
> > > > > > > > > > 4/ Archetypes
> > > > > > > > > > 5/ Tooling
> > > > > > > > > > 6/ Sampels
> > > > > > > > > >
> > > > > > > > > > By categorizing the source it should become easier to
> > read
> > > and
> > > > > > > > therefore
> > > > > > > > > > identifying what SE/BC's/SL's are available should
> > become
> > > more
> > > > > > > > > > obvious, as
> > > > > > > > > > well as cleanly showing what is required for core
> > Container
> > > > > > > > > functionality.
> > > > > > > > > >
> > > > > > > > > > There are a couple of ommissions - first rather than one
> > > > > assembly
> > > > > > > > > > (currently
> > > > > > > > > > apache-servicemix project) I would like to add a root
> > > > > directories
> > > > > > > > called
> > > > > > > > > > assemblies and then create a few packaging (as
> > previously
> > > > > > mentioned)
> > > > > > > > > >
> > > > > > > > > > ie.
> > > > > > > > > >
> > > > > > > > > > assemblies
> > > > > > > > > > \ core-only
> > > > > > > > > > \ core-and-components
> > > > > > > > > > etc.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +1 to this reorg
> > > > > > > > > The question is wether we will release everything at the
> > same
> > > > > time
> > > > > > or
> > > > > > > > not.
> > > > > > > > > Currently, the problem is that we need to build the maven
> > > plugin
> > > > > in
> > > > > > a
> > > > > > > > > first
> > > > > > > > > step,
> > > > > > > > > else maven will not pick it while building the whole
> > source
> > > > > tree.
> > > > > > > > > We could avoid that if we could release the plugin, then
> > use
> > > it
> > > > > to
> > > > > > > > build
> > > > > > > > > the
> > > > > > > > > source tree
> > > > > > > > > (as done in Geronimo). But the maven plugin needs the
> > core
> > > > > > container
> > > > > > > > > before
> > > > > > > > > :(
> > > > > > > > >
> > > > > > > > > The other is the servicemix-components package, there are
> > two
> > > > > ways
> > > > > > to
> > > > > > > > go
> > > > > > > > > > here:
> > > > > > > > > >
> > > > > > > > > > 1/ Break up the components into different service
> > engines
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Or break the components jar into different jars.
> > > > > > > > > This would allow to replace all optional dependencies by
> > non
> > > > > > optional
> > > > > > > > > dependencies
> > > > > > > > > and the maven plugin could be used to generate SU and
> > bundle
> > > all
> > > > > the
> > > > > > > > > necessary dependencies.
> > > > > > > > >
> > > > > > > > > 2/ Turn the servicemix-components jar into an SE, add a
> > > > > > dependencies
> > > > > > > > on
> > > > > > > > > the
> > > > > > > > > > servicemix-lwcontainer and then change all the libs to
> > > > > optional
> > > > > > > > false
> > > > > > > > > >
> > > > > > > > > > I'm not keen on the first way because I think the
> > conversion
> > > > > to
> > > > > > real
> > > > > > > > > SE's
> > > > > > > > > > will take some time and should be given space to make
> > sure
> > > we
> > > > > are
> > > > > > > > able
> > > > > > > > > to
> > > > > > > > > > address things like WSDL for services etc.
> > > > > > > > > >
> > > > > > > > > > In the second option we end up with a large SE though I
> > > > > believe it
> > > > > > > > will
> > > > > > > > > > provide all the functionality, I was thinknig that this
> > > would
> > > > > be
> > > > > > a
> > > > > > > > > > special
> > > > > > > > > > packaging - ie. your can download just that big SE
> > separate
> > > > > from
> > > > > > the
> > > > > > > >
> > > > > > > > > other
> > > > > > > > > > assemblies.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Yeah, maybe. We need to rewrite the examples to be less
> > > > > focused on
> > > > > > > > > servicemix-lwcontainer.
> > > > > > > > >
> > > > > > > > > I would like to try and get a discussion going on this
> > since
> > > > > once
> > > > > > this
> > > > > > > > is
> > > > > > > > > > out of the way we could then look to the work invovled
> > in
> > > > > > converting
> > > > > > > > > some
> > > > > > > > > > of
> > > > > > > > > > the lw-container service engines into more complete JBI
> > > > > Service
> > > > > > > > Engines
> > > > > > > > > > (using the service-engine architype as a basis) and also
> > > work
> > > > > on
> > > > > > > > puting
> > > > > > > > > > more
> > > > > > > > > > WSDL in place for those services :)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > P
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Cheers,
> > > > > > > > > Guillaume Nodet
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
Re: Source re-structuring
Posted by Philip Dodds <ph...@gmail.com>.
will do :)
P
On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> As a workaround, you can copy the jar from
> http://repo.mergere.com/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> to
> ~/.m2/java/xml/jsr173/1.0
>
> I will look at the problem now.
>
> On 8/1/06, Philip Dodds <ph...@gmail.com> wrote:
> >
> > Great! Did you have any luck on the jsr171 dependency?
> >
> > P
> >
> > On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > I have just added some profiles to the build system.
> > > They can be activated using
> > > mvn -Dprofile=name
> > >
> > > where name can be
> > > container => servicemix-services, servicemix-jbi, servicemix-core
> > > tooling => tooling
> > > components => beanflow, components, common, soap, bpe, ...
> > > assembly => samples, apache-servicemix
> > > step1 => container + tooling
> > > step2 => components + assembly
> > >
> > > The default profile will build everything.
> > >
> > > This way, we should be able to build everything on a clean host using
> > > mvn -Dprofile=step1
> > > mvn -Dprofile=step2
> > >
> > >
> > >
> > >
> > > On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > >
> > > > Right.
> > > > I will try maven profiles and see if I can find a way to sort this
> > out.
> > > >
> > > >
> > > > On 8/1/06, Philip Dodds <philip.dodds@gmail.com > wrote:
> > > > >
> > > > > I have thought about splitting the plugin - the only issue i could
> > see
> > > > > is
> > > > > having to add the other plugin to projects to run them under
> > > servicemix
> > > > > or
> > > > > to deploy them. Though splitting would still require use of
> > profiles
> > > to
> > > > > have a core/tooling and everything else profile? Unless we create
> > two
> > > > > tooling directories?
> > > > >
> > > > > Since we have talked about not producing too much change pre-3.0,
> I
> > > > > would
> > > > > push for profiles and then lets try and see when Maven can fix the
> > > issue
> > > > > :)
> > > > >
> > > > > P
> > > > >
> > > > > On 8/1/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > >
> > > > > > I have just seen, thx to a user on the mailing list, that
> > > > > > the maven plugin depends on servicemix-core.
> > > > > > To the mentioned steps won't even work when building from a
> clean
> > > > > > computer.
> > > > > > Afaik, currently, you will need to build servicemix-core and its
> > > > > > dependencies
> > > > > > one by one, to be allow to build the maven plugin, and then the
> > > > > > components.
> > > > > >
> > > > > > Maybe we could use maven profiles to ease that, but I really
> hope
> > > > > > the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> > > > > > in 2.0.5 asap.
> > > > > > Restructuring would help a bit, in that it would allow to build
> > the
> > > > > core
> > > > > > container and its dependencies in one run.
> > > > > >
> > > > > > The other way would be to split to jbi plugin into two different
> > > > > plugins,
> > > > > > one that would contain the maven packaging, and one that would
> > > > > > contain the ant tasks and other goals, like jbi:servicemix.
> > > > > >
> > > > > > Any opinion on what to do ?
> > > > > >
> > > > > > On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > > > > >
> > > > > > > Not really.
> > > > > > > There is a bug in maven which cause maven plugins with
> extension
> > > to
> > > > > not
> > > > > > > being
> > > > > > > used when build in the current build. Not sure I'm very
> clear,
> > > > > here.
> > > > > > > The problem happen when you build from a clean machine.
> > > > > > > You can not do
> > > > > > > mvn install
> > > > > > > from the root and expect everything to work.
> > > > > > > This works for simple maven plugins, but not for plugins using
> > > > > > > "extensions" :(
> > > > > > > You need to do
> > > > > > > mvn -N install
> > > > > > > cd tooling
> > > > > > > mvn install
> > > > > > > cd ..
> > > > > > > mvn install
> > > > > > >
> > > > > > > At least, it is my understanding on how maven currently works.
> > > > > > >
> > > > > > >
> > > > > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > One note on the plugin - with the re-org the build order
> would
> > > > > succeed
> > > > > > > > if
> > > > > > > > you built core first - the tooling - then everything else
> > since
> > > > > > nothing
> > > > > > > > in
> > > > > > > > core requires the plugin
> > > > > > > >
> > > > > > > > P
> > > > > > > >
> > > > > > > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 7/28/06, Philip Dodds < philip.dodds@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > I put together a basic plan (with some help from
> > Guillaume),
> > > > > here
> > > > > > > > > >
> > > > > > > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > > > > > > >
> > > > > > > > > > The purpose of the new structure it two allow cleaner
> > > > > separation
> > > > > > > > > between:
> > > > > > > > > >
> > > > > > > > > > 1/ The JBI Container
> > > > > > > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > > > > > > 3/ Platform specific packaging projects
> > > > > > > > > > 4/ Archetypes
> > > > > > > > > > 5/ Tooling
> > > > > > > > > > 6/ Sampels
> > > > > > > > > >
> > > > > > > > > > By categorizing the source it should become easier to
> read
> > > and
> > > > > > > > therefore
> > > > > > > > > > identifying what SE/BC's/SL's are available should
> become
> > > more
> > > > > > > > > > obvious, as
> > > > > > > > > > well as cleanly showing what is required for core
> > Container
> > > > > > > > > functionality.
> > > > > > > > > >
> > > > > > > > > > There are a couple of ommissions - first rather than one
> > > > > assembly
> > > > > > > > > > (currently
> > > > > > > > > > apache-servicemix project) I would like to add a root
> > > > > directories
> > > > > > > > called
> > > > > > > > > > assemblies and then create a few packaging (as
> previously
> > > > > > mentioned)
> > > > > > > > > >
> > > > > > > > > > ie.
> > > > > > > > > >
> > > > > > > > > > assemblies
> > > > > > > > > > \ core-only
> > > > > > > > > > \ core-and-components
> > > > > > > > > > etc.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +1 to this reorg
> > > > > > > > > The question is wether we will release everything at the
> > same
> > > > > time
> > > > > > or
> > > > > > > > not.
> > > > > > > > > Currently, the problem is that we need to build the maven
> > > plugin
> > > > > in
> > > > > > a
> > > > > > > > > first
> > > > > > > > > step,
> > > > > > > > > else maven will not pick it while building the whole
> source
> > > > > tree.
> > > > > > > > > We could avoid that if we could release the plugin, then
> use
> > > it
> > > > > to
> > > > > > > > build
> > > > > > > > > the
> > > > > > > > > source tree
> > > > > > > > > (as done in Geronimo). But the maven plugin needs the
> core
> > > > > > container
> > > > > > > > > before
> > > > > > > > > :(
> > > > > > > > >
> > > > > > > > > The other is the servicemix-components package, there are
> > two
> > > > > ways
> > > > > > to
> > > > > > > > go
> > > > > > > > > > here:
> > > > > > > > > >
> > > > > > > > > > 1/ Break up the components into different service
> engines
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Or break the components jar into different jars.
> > > > > > > > > This would allow to replace all optional dependencies by
> non
> > > > > > optional
> > > > > > > > > dependencies
> > > > > > > > > and the maven plugin could be used to generate SU and
> bundle
> > > all
> > > > > the
> > > > > > > > > necessary dependencies.
> > > > > > > > >
> > > > > > > > > 2/ Turn the servicemix-components jar into an SE, add a
> > > > > > dependencies
> > > > > > > > on
> > > > > > > > > the
> > > > > > > > > > servicemix-lwcontainer and then change all the libs to
> > > > > optional
> > > > > > > > false
> > > > > > > > > >
> > > > > > > > > > I'm not keen on the first way because I think the
> > conversion
> > > > > to
> > > > > > real
> > > > > > > > > SE's
> > > > > > > > > > will take some time and should be given space to make
> sure
> > > we
> > > > > are
> > > > > > > > able
> > > > > > > > > to
> > > > > > > > > > address things like WSDL for services etc.
> > > > > > > > > >
> > > > > > > > > > In the second option we end up with a large SE though I
> > > > > believe it
> > > > > > > > will
> > > > > > > > > > provide all the functionality, I was thinknig that this
> > > would
> > > > > be
> > > > > > a
> > > > > > > > > > special
> > > > > > > > > > packaging - ie. your can download just that big SE
> > separate
> > > > > from
> > > > > > the
> > > > > > > >
> > > > > > > > > other
> > > > > > > > > > assemblies.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Yeah, maybe. We need to rewrite the examples to be less
> > > > > focused on
> > > > > > > > > servicemix-lwcontainer.
> > > > > > > > >
> > > > > > > > > I would like to try and get a discussion going on this
> since
> > > > > once
> > > > > > this
> > > > > > > > is
> > > > > > > > > > out of the way we could then look to the work invovled
> in
> > > > > > converting
> > > > > > > > > some
> > > > > > > > > > of
> > > > > > > > > > the lw-container service engines into more complete JBI
> > > > > Service
> > > > > > > > Engines
> > > > > > > > > > (using the service-engine architype as a basis) and also
> > > work
> > > > > on
> > > > > > > > puting
> > > > > > > > > > more
> > > > > > > > > > WSDL in place for those services :)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > P
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Cheers,
> > > > > > > > > Guillaume Nodet
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
Re: Source re-structuring
Posted by Guillaume Nodet <gn...@gmail.com>.
As a workaround, you can copy the jar from
http://repo.mergere.com/maven2/stax/stax-api/1.0/stax-api-1.0.jar
to
~/.m2/java/xml/jsr173/1.0
I will look at the problem now.
On 8/1/06, Philip Dodds <ph...@gmail.com> wrote:
>
> Great! Did you have any luck on the jsr171 dependency?
>
> P
>
> On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > I have just added some profiles to the build system.
> > They can be activated using
> > mvn -Dprofile=name
> >
> > where name can be
> > container => servicemix-services, servicemix-jbi, servicemix-core
> > tooling => tooling
> > components => beanflow, components, common, soap, bpe, ...
> > assembly => samples, apache-servicemix
> > step1 => container + tooling
> > step2 => components + assembly
> >
> > The default profile will build everything.
> >
> > This way, we should be able to build everything on a clean host using
> > mvn -Dprofile=step1
> > mvn -Dprofile=step2
> >
> >
> >
> >
> > On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > Right.
> > > I will try maven profiles and see if I can find a way to sort this
> out.
> > >
> > >
> > > On 8/1/06, Philip Dodds <philip.dodds@gmail.com > wrote:
> > > >
> > > > I have thought about splitting the plugin - the only issue i could
> see
> > > > is
> > > > having to add the other plugin to projects to run them under
> > servicemix
> > > > or
> > > > to deploy them. Though splitting would still require use of
> profiles
> > to
> > > > have a core/tooling and everything else profile? Unless we create
> two
> > > > tooling directories?
> > > >
> > > > Since we have talked about not producing too much change pre-3.0, I
> > > > would
> > > > push for profiles and then lets try and see when Maven can fix the
> > issue
> > > > :)
> > > >
> > > > P
> > > >
> > > > On 8/1/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > >
> > > > > I have just seen, thx to a user on the mailing list, that
> > > > > the maven plugin depends on servicemix-core.
> > > > > To the mentioned steps won't even work when building from a clean
> > > > > computer.
> > > > > Afaik, currently, you will need to build servicemix-core and its
> > > > > dependencies
> > > > > one by one, to be allow to build the maven plugin, and then the
> > > > > components.
> > > > >
> > > > > Maybe we could use maven profiles to ease that, but I really hope
> > > > > the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> > > > > in 2.0.5 asap.
> > > > > Restructuring would help a bit, in that it would allow to build
> the
> > > > core
> > > > > container and its dependencies in one run.
> > > > >
> > > > > The other way would be to split to jbi plugin into two different
> > > > plugins,
> > > > > one that would contain the maven packaging, and one that would
> > > > > contain the ant tasks and other goals, like jbi:servicemix.
> > > > >
> > > > > Any opinion on what to do ?
> > > > >
> > > > > On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > > > >
> > > > > > Not really.
> > > > > > There is a bug in maven which cause maven plugins with extension
> > to
> > > > not
> > > > > > being
> > > > > > used when build in the current build. Not sure I'm very clear,
> > > > here.
> > > > > > The problem happen when you build from a clean machine.
> > > > > > You can not do
> > > > > > mvn install
> > > > > > from the root and expect everything to work.
> > > > > > This works for simple maven plugins, but not for plugins using
> > > > > > "extensions" :(
> > > > > > You need to do
> > > > > > mvn -N install
> > > > > > cd tooling
> > > > > > mvn install
> > > > > > cd ..
> > > > > > mvn install
> > > > > >
> > > > > > At least, it is my understanding on how maven currently works.
> > > > > >
> > > > > >
> > > > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > > > >
> > > > > > > One note on the plugin - with the re-org the build order would
> > > > succeed
> > > > > > > if
> > > > > > > you built core first - the tooling - then everything else
> since
> > > > > nothing
> > > > > > > in
> > > > > > > core requires the plugin
> > > > > > >
> > > > > > > P
> > > > > > >
> > > > > > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 7/28/06, Philip Dodds < philip.dodds@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > I put together a basic plan (with some help from
> Guillaume),
> > > > here
> > > > > > > > >
> > > > > > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > > > > > >
> > > > > > > > > The purpose of the new structure it two allow cleaner
> > > > separation
> > > > > > > > between:
> > > > > > > > >
> > > > > > > > > 1/ The JBI Container
> > > > > > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > > > > > 3/ Platform specific packaging projects
> > > > > > > > > 4/ Archetypes
> > > > > > > > > 5/ Tooling
> > > > > > > > > 6/ Sampels
> > > > > > > > >
> > > > > > > > > By categorizing the source it should become easier to read
> > and
> > > > > > > therefore
> > > > > > > > > identifying what SE/BC's/SL's are available should become
> > more
> > > > > > > > > obvious, as
> > > > > > > > > well as cleanly showing what is required for core
> Container
> > > > > > > > functionality.
> > > > > > > > >
> > > > > > > > > There are a couple of ommissions - first rather than one
> > > > assembly
> > > > > > > > > (currently
> > > > > > > > > apache-servicemix project) I would like to add a root
> > > > directories
> > > > > > > called
> > > > > > > > > assemblies and then create a few packaging (as previously
> > > > > mentioned)
> > > > > > > > >
> > > > > > > > > ie.
> > > > > > > > >
> > > > > > > > > assemblies
> > > > > > > > > \ core-only
> > > > > > > > > \ core-and-components
> > > > > > > > > etc.
> > > > > > > >
> > > > > > > >
> > > > > > > > +1 to this reorg
> > > > > > > > The question is wether we will release everything at the
> same
> > > > time
> > > > > or
> > > > > > > not.
> > > > > > > > Currently, the problem is that we need to build the maven
> > plugin
> > > > in
> > > > > a
> > > > > > > > first
> > > > > > > > step,
> > > > > > > > else maven will not pick it while building the whole source
> > > > tree.
> > > > > > > > We could avoid that if we could release the plugin, then use
> > it
> > > > to
> > > > > > > build
> > > > > > > > the
> > > > > > > > source tree
> > > > > > > > (as done in Geronimo). But the maven plugin needs the core
> > > > > container
> > > > > > > > before
> > > > > > > > :(
> > > > > > > >
> > > > > > > > The other is the servicemix-components package, there are
> two
> > > > ways
> > > > > to
> > > > > > > go
> > > > > > > > > here:
> > > > > > > > >
> > > > > > > > > 1/ Break up the components into different service engines
> > > > > > > >
> > > > > > > >
> > > > > > > > Or break the components jar into different jars.
> > > > > > > > This would allow to replace all optional dependencies by non
> > > > > optional
> > > > > > > > dependencies
> > > > > > > > and the maven plugin could be used to generate SU and bundle
> > all
> > > > the
> > > > > > > > necessary dependencies.
> > > > > > > >
> > > > > > > > 2/ Turn the servicemix-components jar into an SE, add a
> > > > > dependencies
> > > > > > > on
> > > > > > > > the
> > > > > > > > > servicemix-lwcontainer and then change all the libs to
> > > > optional
> > > > > > > false
> > > > > > > > >
> > > > > > > > > I'm not keen on the first way because I think the
> conversion
> > > > to
> > > > > real
> > > > > > > > SE's
> > > > > > > > > will take some time and should be given space to make sure
> > we
> > > > are
> > > > > > > able
> > > > > > > > to
> > > > > > > > > address things like WSDL for services etc.
> > > > > > > > >
> > > > > > > > > In the second option we end up with a large SE though I
> > > > believe it
> > > > > > > will
> > > > > > > > > provide all the functionality, I was thinknig that this
> > would
> > > > be
> > > > > a
> > > > > > > > > special
> > > > > > > > > packaging - ie. your can download just that big SE
> separate
> > > > from
> > > > > the
> > > > > > >
> > > > > > > > other
> > > > > > > > > assemblies.
> > > > > > > >
> > > > > > > >
> > > > > > > > Yeah, maybe. We need to rewrite the examples to be less
> > > > focused on
> > > > > > > > servicemix-lwcontainer.
> > > > > > > >
> > > > > > > > I would like to try and get a discussion going on this since
> > > > once
> > > > > this
> > > > > > > is
> > > > > > > > > out of the way we could then look to the work invovled in
> > > > > converting
> > > > > > > > some
> > > > > > > > > of
> > > > > > > > > the lw-container service engines into more complete JBI
> > > > Service
> > > > > > > Engines
> > > > > > > > > (using the service-engine architype as a basis) and also
> > work
> > > > on
> > > > > > > puting
> > > > > > > > > more
> > > > > > > > > WSDL in place for those services :)
> > > > > > > >
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > P
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers,
> > > > > > > > Guillaume Nodet
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Re: Source re-structuring
Posted by Philip Dodds <ph...@gmail.com>.
Great! Did you have any luck on the jsr171 dependency?
P
On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I have just added some profiles to the build system.
> They can be activated using
> mvn -Dprofile=name
>
> where name can be
> container => servicemix-services, servicemix-jbi, servicemix-core
> tooling => tooling
> components => beanflow, components, common, soap, bpe, ...
> assembly => samples, apache-servicemix
> step1 => container + tooling
> step2 => components + assembly
>
> The default profile will build everything.
>
> This way, we should be able to build everything on a clean host using
> mvn -Dprofile=step1
> mvn -Dprofile=step2
>
>
>
>
> On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > Right.
> > I will try maven profiles and see if I can find a way to sort this out.
> >
> >
> > On 8/1/06, Philip Dodds <philip.dodds@gmail.com > wrote:
> > >
> > > I have thought about splitting the plugin - the only issue i could see
> > > is
> > > having to add the other plugin to projects to run them under
> servicemix
> > > or
> > > to deploy them. Though splitting would still require use of profiles
> to
> > > have a core/tooling and everything else profile? Unless we create two
> > > tooling directories?
> > >
> > > Since we have talked about not producing too much change pre-3.0, I
> > > would
> > > push for profiles and then lets try and see when Maven can fix the
> issue
> > > :)
> > >
> > > P
> > >
> > > On 8/1/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > >
> > > > I have just seen, thx to a user on the mailing list, that
> > > > the maven plugin depends on servicemix-core.
> > > > To the mentioned steps won't even work when building from a clean
> > > > computer.
> > > > Afaik, currently, you will need to build servicemix-core and its
> > > > dependencies
> > > > one by one, to be allow to build the maven plugin, and then the
> > > > components.
> > > >
> > > > Maybe we could use maven profiles to ease that, but I really hope
> > > > the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> > > > in 2.0.5 asap.
> > > > Restructuring would help a bit, in that it would allow to build the
> > > core
> > > > container and its dependencies in one run.
> > > >
> > > > The other way would be to split to jbi plugin into two different
> > > plugins,
> > > > one that would contain the maven packaging, and one that would
> > > > contain the ant tasks and other goals, like jbi:servicemix.
> > > >
> > > > Any opinion on what to do ?
> > > >
> > > > On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > > >
> > > > > Not really.
> > > > > There is a bug in maven which cause maven plugins with extension
> to
> > > not
> > > > > being
> > > > > used when build in the current build. Not sure I'm very clear,
> > > here.
> > > > > The problem happen when you build from a clean machine.
> > > > > You can not do
> > > > > mvn install
> > > > > from the root and expect everything to work.
> > > > > This works for simple maven plugins, but not for plugins using
> > > > > "extensions" :(
> > > > > You need to do
> > > > > mvn -N install
> > > > > cd tooling
> > > > > mvn install
> > > > > cd ..
> > > > > mvn install
> > > > >
> > > > > At least, it is my understanding on how maven currently works.
> > > > >
> > > > >
> > > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > > >
> > > > > > One note on the plugin - with the re-org the build order would
> > > succeed
> > > > > > if
> > > > > > you built core first - the tooling - then everything else since
> > > > nothing
> > > > > > in
> > > > > > core requires the plugin
> > > > > >
> > > > > > P
> > > > > >
> > > > > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > > >
> > > > > > > On 7/28/06, Philip Dodds < philip.dodds@gmail.com> wrote:
> > > > > > > >
> > > > > > > > I put together a basic plan (with some help from Guillaume),
> > > here
> > > > > > > >
> > > > > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > > > > >
> > > > > > > > The purpose of the new structure it two allow cleaner
> > > separation
> > > > > > > between:
> > > > > > > >
> > > > > > > > 1/ The JBI Container
> > > > > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > > > > 3/ Platform specific packaging projects
> > > > > > > > 4/ Archetypes
> > > > > > > > 5/ Tooling
> > > > > > > > 6/ Sampels
> > > > > > > >
> > > > > > > > By categorizing the source it should become easier to read
> and
> > > > > > therefore
> > > > > > > > identifying what SE/BC's/SL's are available should become
> more
> > > > > > > > obvious, as
> > > > > > > > well as cleanly showing what is required for core Container
> > > > > > > functionality.
> > > > > > > >
> > > > > > > > There are a couple of ommissions - first rather than one
> > > assembly
> > > > > > > > (currently
> > > > > > > > apache-servicemix project) I would like to add a root
> > > directories
> > > > > > called
> > > > > > > > assemblies and then create a few packaging (as previously
> > > > mentioned)
> > > > > > > >
> > > > > > > > ie.
> > > > > > > >
> > > > > > > > assemblies
> > > > > > > > \ core-only
> > > > > > > > \ core-and-components
> > > > > > > > etc.
> > > > > > >
> > > > > > >
> > > > > > > +1 to this reorg
> > > > > > > The question is wether we will release everything at the same
> > > time
> > > > or
> > > > > > not.
> > > > > > > Currently, the problem is that we need to build the maven
> plugin
> > > in
> > > > a
> > > > > > > first
> > > > > > > step,
> > > > > > > else maven will not pick it while building the whole source
> > > tree.
> > > > > > > We could avoid that if we could release the plugin, then use
> it
> > > to
> > > > > > build
> > > > > > > the
> > > > > > > source tree
> > > > > > > (as done in Geronimo). But the maven plugin needs the core
> > > > container
> > > > > > > before
> > > > > > > :(
> > > > > > >
> > > > > > > The other is the servicemix-components package, there are two
> > > ways
> > > > to
> > > > > > go
> > > > > > > > here:
> > > > > > > >
> > > > > > > > 1/ Break up the components into different service engines
> > > > > > >
> > > > > > >
> > > > > > > Or break the components jar into different jars.
> > > > > > > This would allow to replace all optional dependencies by non
> > > > optional
> > > > > > > dependencies
> > > > > > > and the maven plugin could be used to generate SU and bundle
> all
> > > the
> > > > > > > necessary dependencies.
> > > > > > >
> > > > > > > 2/ Turn the servicemix-components jar into an SE, add a
> > > > dependencies
> > > > > > on
> > > > > > > the
> > > > > > > > servicemix-lwcontainer and then change all the libs to
> > > optional
> > > > > > false
> > > > > > > >
> > > > > > > > I'm not keen on the first way because I think the conversion
> > > to
> > > > real
> > > > > > > SE's
> > > > > > > > will take some time and should be given space to make sure
> we
> > > are
> > > > > > able
> > > > > > > to
> > > > > > > > address things like WSDL for services etc.
> > > > > > > >
> > > > > > > > In the second option we end up with a large SE though I
> > > believe it
> > > > > > will
> > > > > > > > provide all the functionality, I was thinknig that this
> would
> > > be
> > > > a
> > > > > > > > special
> > > > > > > > packaging - ie. your can download just that big SE separate
> > > from
> > > > the
> > > > > >
> > > > > > > other
> > > > > > > > assemblies.
> > > > > > >
> > > > > > >
> > > > > > > Yeah, maybe. We need to rewrite the examples to be less
> > > focused on
> > > > > > > servicemix-lwcontainer.
> > > > > > >
> > > > > > > I would like to try and get a discussion going on this since
> > > once
> > > > this
> > > > > > is
> > > > > > > > out of the way we could then look to the work invovled in
> > > > converting
> > > > > > > some
> > > > > > > > of
> > > > > > > > the lw-container service engines into more complete JBI
> > > Service
> > > > > > Engines
> > > > > > > > (using the service-engine architype as a basis) and also
> work
> > > on
> > > > > > puting
> > > > > > > > more
> > > > > > > > WSDL in place for those services :)
> > > > > > >
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > P
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
Re: Source re-structuring
Posted by Guillaume Nodet <gn...@gmail.com>.
I have just added some profiles to the build system.
They can be activated using
mvn -Dprofile=name
where name can be
container => servicemix-services, servicemix-jbi, servicemix-core
tooling => tooling
components => beanflow, components, common, soap, bpe, ...
assembly => samples, apache-servicemix
step1 => container + tooling
step2 => components + assembly
The default profile will build everything.
This way, we should be able to build everything on a clean host using
mvn -Dprofile=step1
mvn -Dprofile=step2
On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Right.
> I will try maven profiles and see if I can find a way to sort this out.
>
>
> On 8/1/06, Philip Dodds <philip.dodds@gmail.com > wrote:
> >
> > I have thought about splitting the plugin - the only issue i could see
> > is
> > having to add the other plugin to projects to run them under servicemix
> > or
> > to deploy them. Though splitting would still require use of profiles to
> > have a core/tooling and everything else profile? Unless we create two
> > tooling directories?
> >
> > Since we have talked about not producing too much change pre-3.0, I
> > would
> > push for profiles and then lets try and see when Maven can fix the issue
> > :)
> >
> > P
> >
> > On 8/1/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > >
> > > I have just seen, thx to a user on the mailing list, that
> > > the maven plugin depends on servicemix-core.
> > > To the mentioned steps won't even work when building from a clean
> > > computer.
> > > Afaik, currently, you will need to build servicemix-core and its
> > > dependencies
> > > one by one, to be allow to build the maven plugin, and then the
> > > components.
> > >
> > > Maybe we could use maven profiles to ease that, but I really hope
> > > the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> > > in 2.0.5 asap.
> > > Restructuring would help a bit, in that it would allow to build the
> > core
> > > container and its dependencies in one run.
> > >
> > > The other way would be to split to jbi plugin into two different
> > plugins,
> > > one that would contain the maven packaging, and one that would
> > > contain the ant tasks and other goals, like jbi:servicemix.
> > >
> > > Any opinion on what to do ?
> > >
> > > On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > > >
> > > > Not really.
> > > > There is a bug in maven which cause maven plugins with extension to
> > not
> > > > being
> > > > used when build in the current build. Not sure I'm very clear,
> > here.
> > > > The problem happen when you build from a clean machine.
> > > > You can not do
> > > > mvn install
> > > > from the root and expect everything to work.
> > > > This works for simple maven plugins, but not for plugins using
> > > > "extensions" :(
> > > > You need to do
> > > > mvn -N install
> > > > cd tooling
> > > > mvn install
> > > > cd ..
> > > > mvn install
> > > >
> > > > At least, it is my understanding on how maven currently works.
> > > >
> > > >
> > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > >
> > > > > One note on the plugin - with the re-org the build order would
> > succeed
> > > > > if
> > > > > you built core first - the tooling - then everything else since
> > > nothing
> > > > > in
> > > > > core requires the plugin
> > > > >
> > > > > P
> > > > >
> > > > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > > >
> > > > > > On 7/28/06, Philip Dodds < philip.dodds@gmail.com> wrote:
> > > > > > >
> > > > > > > I put together a basic plan (with some help from Guillaume),
> > here
> > > > > > >
> > > > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > > > >
> > > > > > > The purpose of the new structure it two allow cleaner
> > separation
> > > > > > between:
> > > > > > >
> > > > > > > 1/ The JBI Container
> > > > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > > > 3/ Platform specific packaging projects
> > > > > > > 4/ Archetypes
> > > > > > > 5/ Tooling
> > > > > > > 6/ Sampels
> > > > > > >
> > > > > > > By categorizing the source it should become easier to read and
> > > > > therefore
> > > > > > > identifying what SE/BC's/SL's are available should become more
> > > > > > > obvious, as
> > > > > > > well as cleanly showing what is required for core Container
> > > > > > functionality.
> > > > > > >
> > > > > > > There are a couple of ommissions - first rather than one
> > assembly
> > > > > > > (currently
> > > > > > > apache-servicemix project) I would like to add a root
> > directories
> > > > > called
> > > > > > > assemblies and then create a few packaging (as previously
> > > mentioned)
> > > > > > >
> > > > > > > ie.
> > > > > > >
> > > > > > > assemblies
> > > > > > > \ core-only
> > > > > > > \ core-and-components
> > > > > > > etc.
> > > > > >
> > > > > >
> > > > > > +1 to this reorg
> > > > > > The question is wether we will release everything at the same
> > time
> > > or
> > > > > not.
> > > > > > Currently, the problem is that we need to build the maven plugin
> > in
> > > a
> > > > > > first
> > > > > > step,
> > > > > > else maven will not pick it while building the whole source
> > tree.
> > > > > > We could avoid that if we could release the plugin, then use it
> > to
> > > > > build
> > > > > > the
> > > > > > source tree
> > > > > > (as done in Geronimo). But the maven plugin needs the core
> > > container
> > > > > > before
> > > > > > :(
> > > > > >
> > > > > > The other is the servicemix-components package, there are two
> > ways
> > > to
> > > > > go
> > > > > > > here:
> > > > > > >
> > > > > > > 1/ Break up the components into different service engines
> > > > > >
> > > > > >
> > > > > > Or break the components jar into different jars.
> > > > > > This would allow to replace all optional dependencies by non
> > > optional
> > > > > > dependencies
> > > > > > and the maven plugin could be used to generate SU and bundle all
> > the
> > > > > > necessary dependencies.
> > > > > >
> > > > > > 2/ Turn the servicemix-components jar into an SE, add a
> > > dependencies
> > > > > on
> > > > > > the
> > > > > > > servicemix-lwcontainer and then change all the libs to
> > optional
> > > > > false
> > > > > > >
> > > > > > > I'm not keen on the first way because I think the conversion
> > to
> > > real
> > > > > > SE's
> > > > > > > will take some time and should be given space to make sure we
> > are
> > > > > able
> > > > > > to
> > > > > > > address things like WSDL for services etc.
> > > > > > >
> > > > > > > In the second option we end up with a large SE though I
> > believe it
> > > > > will
> > > > > > > provide all the functionality, I was thinknig that this would
> > be
> > > a
> > > > > > > special
> > > > > > > packaging - ie. your can download just that big SE separate
> > from
> > > the
> > > > >
> > > > > > other
> > > > > > > assemblies.
> > > > > >
> > > > > >
> > > > > > Yeah, maybe. We need to rewrite the examples to be less
> > focused on
> > > > > > servicemix-lwcontainer.
> > > > > >
> > > > > > I would like to try and get a discussion going on this since
> > once
> > > this
> > > > > is
> > > > > > > out of the way we could then look to the work invovled in
> > > converting
> > > > > > some
> > > > > > > of
> > > > > > > the lw-container service engines into more complete JBI
> > Service
> > > > > Engines
> > > > > > > (using the service-engine architype as a basis) and also work
> > on
> > > > > puting
> > > > > > > more
> > > > > > > WSDL in place for those services :)
> > > > > >
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > P
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
Re: Source re-structuring
Posted by Guillaume Nodet <gn...@gmail.com>.
Right.
I will try maven profiles and see if I can find a way to sort this out.
On 8/1/06, Philip Dodds <ph...@gmail.com> wrote:
>
> I have thought about splitting the plugin - the only issue i could see is
> having to add the other plugin to projects to run them under servicemix or
> to deploy them. Though splitting would still require use of profiles to
> have a core/tooling and everything else profile? Unless we create two
> tooling directories?
>
> Since we have talked about not producing too much change pre-3.0, I would
> push for profiles and then lets try and see when Maven can fix the issue
> :)
>
> P
>
> On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > I have just seen, thx to a user on the mailing list, that
> > the maven plugin depends on servicemix-core.
> > To the mentioned steps won't even work when building from a clean
> > computer.
> > Afaik, currently, you will need to build servicemix-core and its
> > dependencies
> > one by one, to be allow to build the maven plugin, and then the
> > components.
> >
> > Maybe we could use maven profiles to ease that, but I really hope
> > the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> > in 2.0.5 asap.
> > Restructuring would help a bit, in that it would allow to build the core
> > container and its dependencies in one run.
> >
> > The other way would be to split to jbi plugin into two different
> plugins,
> > one that would contain the maven packaging, and one that would
> > contain the ant tasks and other goals, like jbi:servicemix.
> >
> > Any opinion on what to do ?
> >
> > On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > Not really.
> > > There is a bug in maven which cause maven plugins with extension to
> not
> > > being
> > > used when build in the current build. Not sure I'm very clear, here.
> > > The problem happen when you build from a clean machine.
> > > You can not do
> > > mvn install
> > > from the root and expect everything to work.
> > > This works for simple maven plugins, but not for plugins using
> > > "extensions" :(
> > > You need to do
> > > mvn -N install
> > > cd tooling
> > > mvn install
> > > cd ..
> > > mvn install
> > >
> > > At least, it is my understanding on how maven currently works.
> > >
> > >
> > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > >
> > > > One note on the plugin - with the re-org the build order would
> succeed
> > > > if
> > > > you built core first - the tooling - then everything else since
> > nothing
> > > > in
> > > > core requires the plugin
> > > >
> > > > P
> > > >
> > > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > > >
> > > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > > >
> > > > > > I put together a basic plan (with some help from Guillaume),
> here
> > > > > >
> > > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > > >
> > > > > > The purpose of the new structure it two allow cleaner separation
> > > > > between:
> > > > > >
> > > > > > 1/ The JBI Container
> > > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > > 3/ Platform specific packaging projects
> > > > > > 4/ Archetypes
> > > > > > 5/ Tooling
> > > > > > 6/ Sampels
> > > > > >
> > > > > > By categorizing the source it should become easier to read and
> > > > therefore
> > > > > > identifying what SE/BC's/SL's are available should become more
> > > > > > obvious, as
> > > > > > well as cleanly showing what is required for core Container
> > > > > functionality.
> > > > > >
> > > > > > There are a couple of ommissions - first rather than one
> assembly
> > > > > > (currently
> > > > > > apache-servicemix project) I would like to add a root
> directories
> > > > called
> > > > > > assemblies and then create a few packaging (as previously
> > mentioned)
> > > > > >
> > > > > > ie.
> > > > > >
> > > > > > assemblies
> > > > > > \ core-only
> > > > > > \ core-and-components
> > > > > > etc.
> > > > >
> > > > >
> > > > > +1 to this reorg
> > > > > The question is wether we will release everything at the same time
> > or
> > > > not.
> > > > > Currently, the problem is that we need to build the maven plugin
> in
> > a
> > > > > first
> > > > > step,
> > > > > else maven will not pick it while building the whole source tree.
> > > > > We could avoid that if we could release the plugin, then use it to
> > > > build
> > > > > the
> > > > > source tree
> > > > > (as done in Geronimo). But the maven plugin needs the core
> > container
> > > > > before
> > > > > :(
> > > > >
> > > > > The other is the servicemix-components package, there are two
> ways
> > to
> > > > go
> > > > > > here:
> > > > > >
> > > > > > 1/ Break up the components into different service engines
> > > > >
> > > > >
> > > > > Or break the components jar into different jars.
> > > > > This would allow to replace all optional dependencies by non
> > optional
> > > > > dependencies
> > > > > and the maven plugin could be used to generate SU and bundle all
> the
> > > > > necessary dependencies.
> > > > >
> > > > > 2/ Turn the servicemix-components jar into an SE, add a
> > dependencies
> > > > on
> > > > > the
> > > > > > servicemix-lwcontainer and then change all the libs to optional
> > > > false
> > > > > >
> > > > > > I'm not keen on the first way because I think the conversion to
> > real
> > > > > SE's
> > > > > > will take some time and should be given space to make sure we
> are
> > > > able
> > > > > to
> > > > > > address things like WSDL for services etc.
> > > > > >
> > > > > > In the second option we end up with a large SE though I believe
> it
> > > > will
> > > > > > provide all the functionality, I was thinknig that this would
> be
> > a
> > > > > > special
> > > > > > packaging - ie. your can download just that big SE separate from
> > the
> > > >
> > > > > other
> > > > > > assemblies.
> > > > >
> > > > >
> > > > > Yeah, maybe. We need to rewrite the examples to be less focused
> on
> > > > > servicemix-lwcontainer.
> > > > >
> > > > > I would like to try and get a discussion going on this since once
> > this
> > > > is
> > > > > > out of the way we could then look to the work invovled in
> > converting
> > > > > some
> > > > > > of
> > > > > > the lw-container service engines into more complete JBI Service
> > > > Engines
> > > > > > (using the service-engine architype as a basis) and also work on
> > > > puting
> > > > > > more
> > > > > > WSDL in place for those services :)
> > > > >
> > > > >
> > > > > +1
> > > > >
> > > > > P
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Re: Source re-structuring
Posted by Philip Dodds <ph...@gmail.com>.
I have thought about splitting the plugin - the only issue i could see is
having to add the other plugin to projects to run them under servicemix or
to deploy them. Though splitting would still require use of profiles to
have a core/tooling and everything else profile? Unless we create two
tooling directories?
Since we have talked about not producing too much change pre-3.0, I would
push for profiles and then lets try and see when Maven can fix the issue :)
P
On 8/1/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I have just seen, thx to a user on the mailing list, that
> the maven plugin depends on servicemix-core.
> To the mentioned steps won't even work when building from a clean
> computer.
> Afaik, currently, you will need to build servicemix-core and its
> dependencies
> one by one, to be allow to build the maven plugin, and then the
> components.
>
> Maybe we could use maven profiles to ease that, but I really hope
> the bug http://jira.codehaus.org/browse/MNG-1911 will be fixed
> in 2.0.5 asap.
> Restructuring would help a bit, in that it would allow to build the core
> container and its dependencies in one run.
>
> The other way would be to split to jbi plugin into two different plugins,
> one that would contain the maven packaging, and one that would
> contain the ant tasks and other goals, like jbi:servicemix.
>
> Any opinion on what to do ?
>
> On 7/28/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > Not really.
> > There is a bug in maven which cause maven plugins with extension to not
> > being
> > used when build in the current build. Not sure I'm very clear, here.
> > The problem happen when you build from a clean machine.
> > You can not do
> > mvn install
> > from the root and expect everything to work.
> > This works for simple maven plugins, but not for plugins using
> > "extensions" :(
> > You need to do
> > mvn -N install
> > cd tooling
> > mvn install
> > cd ..
> > mvn install
> >
> > At least, it is my understanding on how maven currently works.
> >
> >
> > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > >
> > > One note on the plugin - with the re-org the build order would succeed
> > > if
> > > you built core first - the tooling - then everything else since
> nothing
> > > in
> > > core requires the plugin
> > >
> > > P
> > >
> > > On 7/28/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> > > >
> > > > On 7/28/06, Philip Dodds <ph...@gmail.com> wrote:
> > > > >
> > > > > I put together a basic plan (with some help from Guillaume), here
> > > > >
> > > > > http://goopen.org/confluence/display/SM/Source+Structure
> > > > >
> > > > > The purpose of the new structure it two allow cleaner separation
> > > > between:
> > > > >
> > > > > 1/ The JBI Container
> > > > > 2/ Deployables such as shared libraries/BC's/SE's
> > > > > 3/ Platform specific packaging projects
> > > > > 4/ Archetypes
> > > > > 5/ Tooling
> > > > > 6/ Sampels
> > > > >
> > > > > By categorizing the source it should become easier to read and
> > > therefore
> > > > > identifying what SE/BC's/SL's are available should become more
> > > > > obvious, as
> > > > > well as cleanly showing what is required for core Container
> > > > functionality.
> > > > >
> > > > > There are a couple of ommissions - first rather than one assembly
> > > > > (currently
> > > > > apache-servicemix project) I would like to add a root directories
> > > called
> > > > > assemblies and then create a few packaging (as previously
> mentioned)
> > > > >
> > > > > ie.
> > > > >
> > > > > assemblies
> > > > > \ core-only
> > > > > \ core-and-components
> > > > > etc.
> > > >
> > > >
> > > > +1 to this reorg
> > > > The question is wether we will release everything at the same time
> or
> > > not.
> > > > Currently, the problem is that we need to build the maven plugin in
> a
> > > > first
> > > > step,
> > > > else maven will not pick it while building the whole source tree.
> > > > We could avoid that if we could release the plugin, then use it to
> > > build
> > > > the
> > > > source tree
> > > > (as done in Geronimo). But the maven plugin needs the core
> container
> > > > before
> > > > :(
> > > >
> > > > The other is the servicemix-components package, there are two ways
> to
> > > go
> > > > > here:
> > > > >
> > > > > 1/ Break up the components into different service engines
> > > >
> > > >
> > > > Or break the components jar into different jars.
> > > > This would allow to replace all optional dependencies by non
> optional
> > > > dependencies
> > > > and the maven plugin could be used to generate SU and bundle all the
> > > > necessary dependencies.
> > > >
> > > > 2/ Turn the servicemix-components jar into an SE, add a
> dependencies
> > > on
> > > > the
> > > > > servicemix-lwcontainer and then change all the libs to optional
> > > false
> > > > >
> > > > > I'm not keen on the first way because I think the conversion to
> real
> > > > SE's
> > > > > will take some time and should be given space to make sure we are
> > > able
> > > > to
> > > > > address things like WSDL for services etc.
> > > > >
> > > > > In the second option we end up with a large SE though I believe it
> > > will
> > > > > provide all the functionality, I was thinknig that this would be
> a
> > > > > special
> > > > > packaging - ie. your can download just that big SE separate from
> the
> > >
> > > > other
> > > > > assemblies.
> > > >
> > > >
> > > > Yeah, maybe. We need to rewrite the examples to be less focused on
> > > > servicemix-lwcontainer.
> > > >
> > > > I would like to try and get a discussion going on this since once
> this
> > > is
> > > > > out of the way we could then look to the work invovled in
> converting
> > > > some
> > > > > of
> > > > > the lw-container service engines into more complete JBI Service
> > > Engines
> > > > > (using the service-engine architype as a basis) and also work on
> > > puting
> > > > > more
> > > > > WSDL in place for those services :)
> > > >
> > > >
> > > > +1
> > > >
> > > > P
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
>
>