Great! Did you have any luck on the jsr171 dependency?
P On 8/1/06, Guillaume Nodet <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On 7/28/06, Philip Dodds < [EMAIL PROTECTED]> 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
