I have just checked in a fix to the root pom to exclude this dependency from xfire-all.
On 8/1/06, Guillaume Nodet <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > -- Cheers, Guillaume Nodet
-- Cheers, Guillaume Nodet
