You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2009/05/18 07:35:14 UTC
[DISCUSS - Camel 2.0] - Move not used components to a sandbox area
Hi
In Camel 2.0 we have several components that are not used, abandoned
and/or in a questionable quality. We have touched this issue before
and kinda agreed to move them to a sandbox area in SVN. Maybe using a
different name.
I have compiled a list for suggested components to be moved:
=================
camel-activemq-web
- not documented
- not used
- Kinda experiment code from James
camel-jhc
- lack quality in codebase
- has not been active maintained for a long time
- not documented
- not used
- and its a constant pain to keep updated when we do cross component
refactorings
camel-jmxconnect
- lack quality in codebase
- has not been active maintained for a long time
- not documented
- not used
camel-spring-javaconfig
- depends on Spring JavaConfig SNAPSHOT
- Spring JavaConfig is kinda @deprecated as its moved to be part of
Spring 3.0 core
- not documented
- not used
- Kinda experiment code from James
- remove the camel-example-spring-javaconfig also
camel-supercsv
- has not been active maintained for a long time
- not documented
- not used
- and we have 2-3 other CSV components (flatpack, csv, bindy)
camel-swing
- has not been active maintained for a long time
- not documented
- not used
- confusing concept what you can integrate with Swing.
- (Kinda experiment code from James)
camel-uface
- has not been active maintained for a long time
- not documented
- not used
- confusing concept what you can integrate with Swing / UFace.
- Kinda experiment code from James
And the next two is more up for debate
===================
camel-testng
- has not been active maintained for a long time
- not documented
- not used
- testng is loosing the battle against JUnit 4.x
camel-hamcrest
- has not been active maintained for a long time
- not documented
- not used
- we do not used it internally for unit testing either
Any thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by Charles Moulliard <cm...@gmail.com>.
Excellent idea to have a sandbox and also to move such components
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
On Mon, Jun 1, 2009 at 10:52 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi Willem
>
> Thanks for the help.
>
> I have moved the components to the sandbox. Their new home is here:
> https://svn.apache.org/repos/asf/camel/sandbox/
>
> And I have changed the various pom.xml files in camel to not include
> these components.
> I cleaned my local m2 repo and did a full rebuild / install. It
> completed on my laptop.
>
> But let me know if you have any problems after upgrading from SVN.
>
>
>
> On Sun, May 31, 2009 at 9:41 AM, Willem Jiang <wi...@gmail.com>
> wrote:
> > Hi Claus
> >
> > You can create the directory yourself with the svn command line.
> > svn mkdir https://svn.apache.org/repos/asf/camel/sandbox
> > The you can check out this direct in you local work space and add the
> > files that you want.
> > If you want to move the below components into the sandbox, please use
> > the "svn move" command
> > In this way, we can trace back the change histories from the module in
> > the sandbox
> >
> > BTW, please remember to remove the assembly descriptions of this
> > components in apache-camel module.
> >
> > Willem
> >
> > Claus Ibsen wrote:
> >> Hi
> >>
> >> To sum up the list of components to be moved to a sandbox area are:
> >> - camel-activemq-web
> >> - camel-supercsv
> >> - camel-swing
> >> - camel-uface
> >> - camel-hamcrest
> >> - camel-jhc
> >>
> >> Who can help me setup the sandbox in the SVN and move the components?
> >>
> >>
> >>
> >>
> >> On Tue, May 19, 2009 at 10:17 AM, James Strachan
> >> <ja...@gmail.com> wrote:
> >>> Damn, I forgot how much crappy unfinished code I'd written - great
> >>> catch Claus :)
> >>>
> >>> 2009/5/18 Claus Ibsen <cl...@gmail.com>:
> >>>> Hi
> >>>>
> >>>> In Camel 2.0 we have several components that are not used, abandoned
> >>>> and/or in a questionable quality. We have touched this issue before
> >>>> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
> >>>> different name.
> >>> Having a sandbox project in subversion (say at
> >>> https://svn.apache.org/repos/asf/camel/sandbox/) sounds like a good
> >>> idea (like Commons at Apache or Mojo at codehaus etc).
> >>>
> >>> Leaving the sandbox as a fully working maven multi-project (so folks
> >>> can build/run/test the sandbox components) can act as a little
> >>> experimentation area where folks can drop in all kinds of wacky ideas
> >>> and experiments until they blossom into a fully formed component we
> >>> can add to the main trunk?
> >>>
> >>>
> >>>
> >>>> I have compiled a list for suggested components to be moved:
> >>>> =================
> >>>>
> >>>> camel-activemq-web
> >>>> - not documented
> >>>> - not used
> >>>> - Kinda experiment code from James
> >>> I needed this for testing of Camel, ActiveMQ and camel-web; but since
> >>> it doesn't have any actual test cases I guess we can zap it :)
> >>>
> >>>
> >>>> camel-spring-javaconfig
> >>>> - depends on Spring JavaConfig SNAPSHOT
> >>>> - Spring JavaConfig is kinda @deprecated as its moved to be part of
> >>>> Spring 3.0 core
> >>>> - not documented
> >>>> - not used
> >>>> - Kinda experiment code from James
> >>>> - remove the camel-example-spring-javaconfig also
> >>> As Willem said - since JavaConfig is part of Spring 3, we should
> >>> absolutely have JavaConfig support out of the box
> >>>
> >>>
> >>>> camel-supercsv
> >>>> - has not been active maintained for a long time
> >>>> - not documented
> >>>> - not used
> >>>> - and we have 2-3 other CSV components (flatpack, csv, bindy)
> >>>>
> >>>>
> >>>> camel-swing
> >>>> - has not been active maintained for a long time
> >>>> - not documented
> >>>> - not used
> >>>> - confusing concept what you can integrate with Swing.
> >>>> - (Kinda experiment code from James)
> >>>>
> >>>>
> >>>> camel-uface
> >>>> - has not been active maintained for a long time
> >>>> - not documented
> >>>> - not used
> >>>> - confusing concept what you can integrate with Swing / UFace.
> >>>> - Kinda experiment code from James
> >>> Agreed with all the others above.
> >>>
> >>>
> >>>
> >>>> And the next two is more up for debate
> >>>> ===================
> >>>>
> >>>> camel-testng
> >>>> - has not been active maintained for a long time
> >>>> - not documented
> >>>> - not used
> >>>> - testng is loosing the battle against JUnit 4.x
> >>> Yeah, its still of limited use
> >>>
> >>>
> >>>> camel-hamcrest
> >>>> - has not been active maintained for a long time
> >>>> - not documented
> >>>> - not used
> >>>> - we do not used it internally for unit testing either
> >>> Agreed. I hoped to round out this library one day to a bunch more
> >>> useful assertions, but have never got the chance.
> >>>
> >>> Sorry! :)
> >>>
> >>> --
> >>> James
> >>> -------
> >>> http://macstrac.blogspot.com/
> >>>
> >>> Open Source Integration
> >>> http://fusesource.com/
> >>>
> >>
> >>
> >>
> >
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Willem
Thanks for the help.
I have moved the components to the sandbox. Their new home is here:
https://svn.apache.org/repos/asf/camel/sandbox/
And I have changed the various pom.xml files in camel to not include
these components.
I cleaned my local m2 repo and did a full rebuild / install. It
completed on my laptop.
But let me know if you have any problems after upgrading from SVN.
On Sun, May 31, 2009 at 9:41 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Claus
>
> You can create the directory yourself with the svn command line.
> svn mkdir https://svn.apache.org/repos/asf/camel/sandbox
> The you can check out this direct in you local work space and add the
> files that you want.
> If you want to move the below components into the sandbox, please use
> the "svn move" command
> In this way, we can trace back the change histories from the module in
> the sandbox
>
> BTW, please remember to remove the assembly descriptions of this
> components in apache-camel module.
>
> Willem
>
> Claus Ibsen wrote:
>> Hi
>>
>> To sum up the list of components to be moved to a sandbox area are:
>> - camel-activemq-web
>> - camel-supercsv
>> - camel-swing
>> - camel-uface
>> - camel-hamcrest
>> - camel-jhc
>>
>> Who can help me setup the sandbox in the SVN and move the components?
>>
>>
>>
>>
>> On Tue, May 19, 2009 at 10:17 AM, James Strachan
>> <ja...@gmail.com> wrote:
>>> Damn, I forgot how much crappy unfinished code I'd written - great
>>> catch Claus :)
>>>
>>> 2009/5/18 Claus Ibsen <cl...@gmail.com>:
>>>> Hi
>>>>
>>>> In Camel 2.0 we have several components that are not used, abandoned
>>>> and/or in a questionable quality. We have touched this issue before
>>>> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
>>>> different name.
>>> Having a sandbox project in subversion (say at
>>> https://svn.apache.org/repos/asf/camel/sandbox/) sounds like a good
>>> idea (like Commons at Apache or Mojo at codehaus etc).
>>>
>>> Leaving the sandbox as a fully working maven multi-project (so folks
>>> can build/run/test the sandbox components) can act as a little
>>> experimentation area where folks can drop in all kinds of wacky ideas
>>> and experiments until they blossom into a fully formed component we
>>> can add to the main trunk?
>>>
>>>
>>>
>>>> I have compiled a list for suggested components to be moved:
>>>> =================
>>>>
>>>> camel-activemq-web
>>>> - not documented
>>>> - not used
>>>> - Kinda experiment code from James
>>> I needed this for testing of Camel, ActiveMQ and camel-web; but since
>>> it doesn't have any actual test cases I guess we can zap it :)
>>>
>>>
>>>> camel-spring-javaconfig
>>>> - depends on Spring JavaConfig SNAPSHOT
>>>> - Spring JavaConfig is kinda @deprecated as its moved to be part of
>>>> Spring 3.0 core
>>>> - not documented
>>>> - not used
>>>> - Kinda experiment code from James
>>>> - remove the camel-example-spring-javaconfig also
>>> As Willem said - since JavaConfig is part of Spring 3, we should
>>> absolutely have JavaConfig support out of the box
>>>
>>>
>>>> camel-supercsv
>>>> - has not been active maintained for a long time
>>>> - not documented
>>>> - not used
>>>> - and we have 2-3 other CSV components (flatpack, csv, bindy)
>>>>
>>>>
>>>> camel-swing
>>>> - has not been active maintained for a long time
>>>> - not documented
>>>> - not used
>>>> - confusing concept what you can integrate with Swing.
>>>> - (Kinda experiment code from James)
>>>>
>>>>
>>>> camel-uface
>>>> - has not been active maintained for a long time
>>>> - not documented
>>>> - not used
>>>> - confusing concept what you can integrate with Swing / UFace.
>>>> - Kinda experiment code from James
>>> Agreed with all the others above.
>>>
>>>
>>>
>>>> And the next two is more up for debate
>>>> ===================
>>>>
>>>> camel-testng
>>>> - has not been active maintained for a long time
>>>> - not documented
>>>> - not used
>>>> - testng is loosing the battle against JUnit 4.x
>>> Yeah, its still of limited use
>>>
>>>
>>>> camel-hamcrest
>>>> - has not been active maintained for a long time
>>>> - not documented
>>>> - not used
>>>> - we do not used it internally for unit testing either
>>> Agreed. I hoped to round out this library one day to a bunch more
>>> useful assertions, but have never got the chance.
>>>
>>> Sorry! :)
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.com/
>>>
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus
You can create the directory yourself with the svn command line.
svn mkdir https://svn.apache.org/repos/asf/camel/sandbox
The you can check out this direct in you local work space and add the
files that you want.
If you want to move the below components into the sandbox, please use
the "svn move" command
In this way, we can trace back the change histories from the module in
the sandbox
BTW, please remember to remove the assembly descriptions of this
components in apache-camel module.
Willem
Claus Ibsen wrote:
> Hi
>
> To sum up the list of components to be moved to a sandbox area are:
> - camel-activemq-web
> - camel-supercsv
> - camel-swing
> - camel-uface
> - camel-hamcrest
> - camel-jhc
>
> Who can help me setup the sandbox in the SVN and move the components?
>
>
>
>
> On Tue, May 19, 2009 at 10:17 AM, James Strachan
> <ja...@gmail.com> wrote:
>> Damn, I forgot how much crappy unfinished code I'd written - great
>> catch Claus :)
>>
>> 2009/5/18 Claus Ibsen <cl...@gmail.com>:
>>> Hi
>>>
>>> In Camel 2.0 we have several components that are not used, abandoned
>>> and/or in a questionable quality. We have touched this issue before
>>> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
>>> different name.
>> Having a sandbox project in subversion (say at
>> https://svn.apache.org/repos/asf/camel/sandbox/) sounds like a good
>> idea (like Commons at Apache or Mojo at codehaus etc).
>>
>> Leaving the sandbox as a fully working maven multi-project (so folks
>> can build/run/test the sandbox components) can act as a little
>> experimentation area where folks can drop in all kinds of wacky ideas
>> and experiments until they blossom into a fully formed component we
>> can add to the main trunk?
>>
>>
>>
>>> I have compiled a list for suggested components to be moved:
>>> =================
>>>
>>> camel-activemq-web
>>> - not documented
>>> - not used
>>> - Kinda experiment code from James
>> I needed this for testing of Camel, ActiveMQ and camel-web; but since
>> it doesn't have any actual test cases I guess we can zap it :)
>>
>>
>>> camel-spring-javaconfig
>>> - depends on Spring JavaConfig SNAPSHOT
>>> - Spring JavaConfig is kinda @deprecated as its moved to be part of
>>> Spring 3.0 core
>>> - not documented
>>> - not used
>>> - Kinda experiment code from James
>>> - remove the camel-example-spring-javaconfig also
>> As Willem said - since JavaConfig is part of Spring 3, we should
>> absolutely have JavaConfig support out of the box
>>
>>
>>> camel-supercsv
>>> - has not been active maintained for a long time
>>> - not documented
>>> - not used
>>> - and we have 2-3 other CSV components (flatpack, csv, bindy)
>>>
>>>
>>> camel-swing
>>> - has not been active maintained for a long time
>>> - not documented
>>> - not used
>>> - confusing concept what you can integrate with Swing.
>>> - (Kinda experiment code from James)
>>>
>>>
>>> camel-uface
>>> - has not been active maintained for a long time
>>> - not documented
>>> - not used
>>> - confusing concept what you can integrate with Swing / UFace.
>>> - Kinda experiment code from James
>> Agreed with all the others above.
>>
>>
>>
>>> And the next two is more up for debate
>>> ===================
>>>
>>> camel-testng
>>> - has not been active maintained for a long time
>>> - not documented
>>> - not used
>>> - testng is loosing the battle against JUnit 4.x
>> Yeah, its still of limited use
>>
>>
>>> camel-hamcrest
>>> - has not been active maintained for a long time
>>> - not documented
>>> - not used
>>> - we do not used it internally for unit testing either
>> Agreed. I hoped to round out this library one day to a bunch more
>> useful assertions, but have never got the chance.
>>
>> Sorry! :)
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>
>
>
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
To sum up the list of components to be moved to a sandbox area are:
- camel-activemq-web
- camel-supercsv
- camel-swing
- camel-uface
- camel-hamcrest
- camel-jhc
Who can help me setup the sandbox in the SVN and move the components?
On Tue, May 19, 2009 at 10:17 AM, James Strachan
<ja...@gmail.com> wrote:
> Damn, I forgot how much crappy unfinished code I'd written - great
> catch Claus :)
>
> 2009/5/18 Claus Ibsen <cl...@gmail.com>:
>> Hi
>>
>> In Camel 2.0 we have several components that are not used, abandoned
>> and/or in a questionable quality. We have touched this issue before
>> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
>> different name.
>
> Having a sandbox project in subversion (say at
> https://svn.apache.org/repos/asf/camel/sandbox/) sounds like a good
> idea (like Commons at Apache or Mojo at codehaus etc).
>
> Leaving the sandbox as a fully working maven multi-project (so folks
> can build/run/test the sandbox components) can act as a little
> experimentation area where folks can drop in all kinds of wacky ideas
> and experiments until they blossom into a fully formed component we
> can add to the main trunk?
>
>
>
>> I have compiled a list for suggested components to be moved:
>> =================
>>
>> camel-activemq-web
>> - not documented
>> - not used
>> - Kinda experiment code from James
>
> I needed this for testing of Camel, ActiveMQ and camel-web; but since
> it doesn't have any actual test cases I guess we can zap it :)
>
>
>> camel-spring-javaconfig
>> - depends on Spring JavaConfig SNAPSHOT
>> - Spring JavaConfig is kinda @deprecated as its moved to be part of
>> Spring 3.0 core
>> - not documented
>> - not used
>> - Kinda experiment code from James
>> - remove the camel-example-spring-javaconfig also
>
> As Willem said - since JavaConfig is part of Spring 3, we should
> absolutely have JavaConfig support out of the box
>
>
>> camel-supercsv
>> - has not been active maintained for a long time
>> - not documented
>> - not used
>> - and we have 2-3 other CSV components (flatpack, csv, bindy)
>>
>>
>> camel-swing
>> - has not been active maintained for a long time
>> - not documented
>> - not used
>> - confusing concept what you can integrate with Swing.
>> - (Kinda experiment code from James)
>>
>>
>> camel-uface
>> - has not been active maintained for a long time
>> - not documented
>> - not used
>> - confusing concept what you can integrate with Swing / UFace.
>> - Kinda experiment code from James
>
> Agreed with all the others above.
>
>
>
>> And the next two is more up for debate
>> ===================
>>
>> camel-testng
>> - has not been active maintained for a long time
>> - not documented
>> - not used
>> - testng is loosing the battle against JUnit 4.x
>
> Yeah, its still of limited use
>
>
>> camel-hamcrest
>> - has not been active maintained for a long time
>> - not documented
>> - not used
>> - we do not used it internally for unit testing either
>
> Agreed. I hoped to round out this library one day to a bunch more
> useful assertions, but have never got the chance.
>
> Sorry! :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by James Strachan <ja...@gmail.com>.
Damn, I forgot how much crappy unfinished code I'd written - great
catch Claus :)
2009/5/18 Claus Ibsen <cl...@gmail.com>:
> Hi
>
> In Camel 2.0 we have several components that are not used, abandoned
> and/or in a questionable quality. We have touched this issue before
> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
> different name.
Having a sandbox project in subversion (say at
https://svn.apache.org/repos/asf/camel/sandbox/) sounds like a good
idea (like Commons at Apache or Mojo at codehaus etc).
Leaving the sandbox as a fully working maven multi-project (so folks
can build/run/test the sandbox components) can act as a little
experimentation area where folks can drop in all kinds of wacky ideas
and experiments until they blossom into a fully formed component we
can add to the main trunk?
> I have compiled a list for suggested components to be moved:
> =================
>
> camel-activemq-web
> - not documented
> - not used
> - Kinda experiment code from James
I needed this for testing of Camel, ActiveMQ and camel-web; but since
it doesn't have any actual test cases I guess we can zap it :)
> camel-spring-javaconfig
> - depends on Spring JavaConfig SNAPSHOT
> - Spring JavaConfig is kinda @deprecated as its moved to be part of
> Spring 3.0 core
> - not documented
> - not used
> - Kinda experiment code from James
> - remove the camel-example-spring-javaconfig also
As Willem said - since JavaConfig is part of Spring 3, we should
absolutely have JavaConfig support out of the box
> camel-supercsv
> - has not been active maintained for a long time
> - not documented
> - not used
> - and we have 2-3 other CSV components (flatpack, csv, bindy)
>
>
> camel-swing
> - has not been active maintained for a long time
> - not documented
> - not used
> - confusing concept what you can integrate with Swing.
> - (Kinda experiment code from James)
>
>
> camel-uface
> - has not been active maintained for a long time
> - not documented
> - not used
> - confusing concept what you can integrate with Swing / UFace.
> - Kinda experiment code from James
Agreed with all the others above.
> And the next two is more up for debate
> ===================
>
> camel-testng
> - has not been active maintained for a long time
> - not documented
> - not used
> - testng is loosing the battle against JUnit 4.x
Yeah, its still of limited use
> camel-hamcrest
> - has not been active maintained for a long time
> - not documented
> - not used
> - we do not used it internally for unit testing either
Agreed. I hoped to round out this library one day to a bunch more
useful assertions, but have never got the chance.
Sorry! :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus,
I think we should keep the camel-spring-javaconfig.
We *have* the document[1] and example[2] for it.
With the camel-spring-javaconfig, we could write the rule with DSL
without touching any XML configuration, specially the <package> tag.
<camelContext xmlns="http://camel.apache.org/schema/spring">
<package>org.apache.camel.spring.config.scan.route</package>
</camelContext>
[1]http://camel.apache.org/spring-java-config.html
[2]http://camel.apache.org/spring-java-config-example.html
Willem
Claus Ibsen wrote:
> Hi
>
> In Camel 2.0 we have several components that are not used, abandoned
> and/or in a questionable quality. We have touched this issue before
> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
> different name.
>
> I have compiled a list for suggested components to be moved:
> =================
>
> camel-activemq-web
> - not documented
> - not used
> - Kinda experiment code from James
>
>
> camel-jhc
> - lack quality in codebase
> - has not been active maintained for a long time
> - not documented
> - not used
> - and its a constant pain to keep updated when we do cross component
> refactorings
>
>
> camel-jmxconnect
> - lack quality in codebase
> - has not been active maintained for a long time
> - not documented
> - not used
>
>
> camel-spring-javaconfig
> - depends on Spring JavaConfig SNAPSHOT
> - Spring JavaConfig is kinda @deprecated as its moved to be part of
> Spring 3.0 core
> - not documented
> - not used
> - Kinda experiment code from James
> - remove the camel-example-spring-javaconfig also
>
>
> camel-supercsv
> - has not been active maintained for a long time
> - not documented
> - not used
> - and we have 2-3 other CSV components (flatpack, csv, bindy)
>
>
> camel-swing
> - has not been active maintained for a long time
> - not documented
> - not used
> - confusing concept what you can integrate with Swing.
> - (Kinda experiment code from James)
>
>
> camel-uface
> - has not been active maintained for a long time
> - not documented
> - not used
> - confusing concept what you can integrate with Swing / UFace.
> - Kinda experiment code from James
>
>
> And the next two is more up for debate
> ===================
>
> camel-testng
> - has not been active maintained for a long time
> - not documented
> - not used
> - testng is loosing the battle against JUnit 4.x
>
>
> camel-hamcrest
> - has not been active maintained for a long time
> - not documented
> - not used
> - we do not used it internally for unit testing either
>
>
> Any thoughts?
>
>
Re: [DISCUSS - Camel 2.0] - Move not used components to a sandbox
area
Posted by Bruce Snyder <br...@gmail.com>.
On Sun, May 17, 2009 at 11:35 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> In Camel 2.0 we have several components that are not used, abandoned
> and/or in a questionable quality. We have touched this issue before
> and kinda agreed to move them to a sandbox area in SVN. Maybe using a
> different name.
>
> I have compiled a list for suggested components to be moved:
> =================
...
> camel-jmxconnect
> - lack quality in codebase
> - has not been active maintained for a long time
> - not documented
> - not used
I'd like to keep this component around as I'd like to work on it to
improve it and build it out further.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder