kitplummer wrote:
>
> On 7/5/07, Mark T. <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> kitplummer wrote:
>> >
>> > On 7/5/07, Mark T. <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> kitplummer wrote:
>> >> >
>> >> > On 7/5/07, Mark T. <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> kitplummer wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Mark T. wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> bsnyder wrote:
>> >> >> >>>
>> >> >> >>> On 7/3/07, Mark T. <[EMAIL PROTECTED]> wrote:
>> >> >> >>>>
>> >> >> >>>> If I am only using the binary installations of ServiceMix. Do
>> I
>> >> >> have
>> >> >> >>>> to have
>> >> >> >>>> maven installed?
>> >> >> >>>>
>> >> >> >>>> I am planning on using ant for any JBI packaging or static
>> >> >> >>>> configuration.
>> >> >> >>>
>> >> >> >>> No, Maven is not required if you're only using the binary
>> >> download.
>> >> >> >>> Maven is required if you are:
>> >> >> >>>
>> >> >> >>> a) Building the ServiceMix source code
>> >> >> >>> b) Using ServiceMix Maven archetypes to create SU and SA
>> project
>> >> >> >>> skeletons
>> >> >> >>>
>> >> >> >>> Bruce
>> >> >> >>> --
>> >> >> >>> perl -e 'print
>> >> >> >>>
>> >> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> >> >> >>> );'
>> >> >> >>>
>> >> >> >>> Apache Geronimo - http://geronimo.apache.org/
>> >> >> >>> Apache ActiveMQ - http://activemq.org/
>> >> >> >>> Apache ServiceMix - http://servicemix.org/
>> >> >> >>> Castor - http://castor.org/
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >> Can you clarify SU and SA? thanks.
>> >> >> >>
>> >> >> >
>> >> >> > I finally got my blog back up. I'd posted a screencast of
>> putting
>> >> >> > together a SU/SA package a while back - think it might be
>> beneficial
>> >> to
>> >> >> > see the power of the maven archetypes.
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> http://www.blackholelogic.com/assets/2007/7/5/servicemix-lwcontainer_screencast.mov
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> Thanks for all the info. The main point I am curious to find out
>> is
>> >> >> that
>> >> >> while most of the examples, in the links that were provided, use
>> maven
>> >> to
>> >> >> create SU/SA packages. Is it possible to create functioning SU/SA
>> >> >> packages
>> >> >> with out using Maven? Is there a significant difference in effort
>> to
>> >> >> create
>> >> >> the packages in something other than maven? Thanks
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/ServiceMix-without-Maven-tf4020828s12049.html#a11448595
>> >> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> > I think you've answered your own question. The lack of
>> >> > examples/documentation on using Ant to package JBI stuff would
>> signify
>> >> > a difference of effort. I believe some of the examples still have
>> Ant
>> >> > builds - but, I don't think they really show any of the packaging
>> >> > (SA). Might check the loan-broker example.
>> >> >
>> >> > Is there a reason why you want to stay away from Maven?
>> >> >
>> >> >
>> >>
>> >> Thanks for the answer. As a system administrator I am trying to
>> >> determine
>> >> requirements for the use/support for ServiceMix and or Maven. As
>> Maven
>> >> would require an additional repository to maintain in my environment,
>> I
>> >> was
>> >> curious if not using Maven was an option; while still providing
>> >> developers
>> >> the tools to develop and deploy packages to Service Mix.
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/ServiceMix-without-Maven-tf4020828s12049.html#a11449461
>> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >>
>> >>
>> > Yep. Been there.
>> >
>> > I realize there's a bit of a learning curve (more so than Ant) to
>> > Maven. But, the overhead (resources) required by Maven is well worth
>> > the efficiency in development. My employer was very hesitant about
>> > Maven and the management of Open libraries and their versions -
>> > initially. We've come to greatly value what the public and local
>> > Maven repos provide. As you build SE/BC/SA/SU components having a
>> > local repository is of great value.
>> >
>> > What we do locally is embed a Maven repo inside of a Subversion
>> > repository. This way we can control library versions, and lock-down
>> > for access control. So, if a particular component requires some
>> > special version we can capture it locally, and reference it from
>> > Maven's pom.xml in the component. We also use the same repository to
>> > home internally developed components - as to be used by anyone inside
>> > our company firewall.
>> >
>> > We've also come to greatly appreciate Maven's integration with
>> > Continuum as well as many of the other plugins (Javadoc generation,
>> > site generation, etc.). Dependency management is huge though - and I
>> > don't think there is anything even remotely close from any other tool.
>> > By using Maven's site building plugin we get a fabricated transitive
>> > dependency report which we use in Technology Readiness Reviews (before
>> > we go production). We know EXACTLY what is needed to deploy.
>> >
>> > Anyway - don't get hung up on Mavens steep learning curve...and don't
>> > let developer's laziness curb you either. Ant is nice - but, Maven is
>> > powerful.
>> >
>> >
>>
>>
>> That is the exact position that I am currently in. I am very reluctant
>> at
>> this moment to use Maven. Specifically the versioning and management of
>> the
>> repository. We must have the ability to certify our product will work
>> when
>> building against maven. Management of the various dependency versions
>> seems
>> to be a huge headache waiting to happen.
>>
>> The site building plugin you mentioned. Does that report on the exact
>> dependency versions in the Maven repository or the required dependency
>> version as required by a project?
>>
>> I am currently trying to wrap my brain around Maven, to see what can/has
>> to
>> be done.... I have a long way to go. Thanks for all of your input.
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/ServiceMix-without-Maven-tf4020828s12049.html#a11454379
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> Hey Mark. It sounds like you are afraid of Maven's capabilities that
> will actually solve exactly the problem you described. By specifying
> a dependency's version for each project it is possible to control what
> library is compiled against, packaged, and deployed.
>
> Here's a snip:
>
> <properties>
> <servicemix-version>fuse-3.1.1.0</servicemix-version>
> </properties>
> <dependencies>
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-lwcontainer</artifactId>
> <version>${servicemix-version}</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-components</artifactId>
> <version>${servicemix-version}</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-common</artifactId>
> <version>${servicemix-version}</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-core</artifactId>
> <version>${servicemix-version}</version>
> <scope>provided</scope>
> </dependency>
> ...
>
> You can see the <version> element describes exactly which version of
> the library is used. The <scope> element defines whether or not that
> library is packaged up with the SA or SU. If you use provided, then
> the library must exists somewhere on the classpath already.
>
> I would suggest a quick study of an example pom.xml.
>
> One of the problem libraries we have is Castor. There's a maven
> plugin that we use that automatically builds Java objects from a
> XSDs...well, the plugin has dependencies that don't match the version
> of Castor we deploy. By controlling this from within Maven's pom.xml
> structure we can ensure the service gets built to specification.
>
> The site plugin's transitive dependency report shows exactly what is
> required by/and used by the project. It is very handy.
>
> Kit
>
>
I will be the first to admit, most of my fears are based upon a lack of
Maven knowledge.. The more I read/hear it seems that Maven will be able to
address my concerns.
--
View this message in context:
http://www.nabble.com/ServiceMix-without-Maven-tf4020828s12049.html#a11469231
Sent from the ServiceMix - User mailing list archive at Nabble.com.
