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
