Of course, for external (non James) dependencies, we should only use
RELEASE versions, except if a dev works in a sandbox or in a non
enrolled module.
Thx, Eric
On 08/02/2013 10:02, Eric Charles wrote:
Hi Ioan,
I don't think it is a good strategy to forbid using SNAPSHOT because we
would sto
Hi Ioan,
I don't think it is a good strategy to forbid using SNAPSHOT because we
would stop integration development between subproject.
If I add a new feature in mailbox, it is to be able to use it in server.
And I want to commit my devs so that everybody can see them and and use
them.
Thx
Hello Eric,
Great, I'm looking forward for that commit. Not related to that, I
think we should adopt a policy NOT to use SNAPSHOT versions of our
artifacts in Server.
We should use releases and if we need to use a new version of
protocols or mailbox than we should make a new release of those
artif
Hi Ioan,
I will commit in 1 minutes the missing bits to make james server work on
IMAP (my last commits make the injection failing).
I will after check that all unit tests succeed, also the karaf ones
which so far are still successfull (the ./build.sh script).
Thx, Eric
On 08/02/2013 08:02
Hello Eric,
That's great. You got me started on the subject. I'm trying to figure
out how to fix the tests that fail in protocols-smtp because of
missing injection.
Cheers,
--
Ioan Eugen Stan
-
To unsubscribe, e-mail: server-de
Hi Ioan,
Thx for this.
I have a long time pending branch related to JAMES-1237 where last
comment was replacing @Resource with @Inject to prepare guice injection.
I will now commit a first version and will continue to fix the last bits
tomorrow.
I have create JAMES-1477 to track down this.
Hello Eric,
I've committed the changes and switched to commons-configuration as it
should have been. Next, I'm moving to fix app to import spring
configs.
Cheers,
--
Ioan Eugen Stan
-
To unsubscribe, e-mail: server-dev-unsubscr
Hello Eric,
Sorry about that. It's my fault for not using git svn the right way. I
will re-commit after your revert.
Thanks,
--
Ioan Eugen Stan
-
To unsubscribe, e-mail: [email protected]
For additional c
On 07/02/2013 11:48, Eric Charles wrote:
Hi Ioan,
It's even worth than I tought.
read worse, not worth
There are now some org.apache.servicemix.bundles.commons-configuration
all over the place in all modules.
I for now revert, exclude commons-configuration and redeclare
org.apache.servic
Hi Ioan,
It's even worth than I tought.
There are now some org.apache.servicemix.bundles.commons-configuration
all over the place in all modules.
I for now revert, exclude commons-configuration and redeclare
org.apache.servicemix.bundles.commons-configuration in the karaf modules.
Thx, Eric
Hi Ioan,
See my reply on previous mail.
org.apache.servicemix.bundles.commons-configuration should only be
declared in karaf modules.
Thx, Eric
On 07/02/2013 11:06, Ioan Eugen Stan wrote:
Hello,
Thanks Eric. It should be committed in a few minutes. Could you give
me some clues as to how c
Hello,
Thanks Eric. It should be committed in a few minutes. Could you give
me some clues as to how components depend on one-another?
DNSService has the least dependencies, which should I try to add next? Queues?
Cheers,
--
Ioan Eugen Stan
-
Thx Ioan.
Feel free to welcome karak in james trunk.
Eric
On 07/02/2013 10:06, Ioan Eugen Stan wrote:
Hello Eric,
We are actually running commons-configuration 1.9. I've created a
bundle for it via ServiceMix but I made a typo in the artifact name
[1], [2].
It's quite an easy thing to do to rep
Hello Eric,
We are actually running commons-configuration 1.9. I've created a
bundle for it via ServiceMix but I made a typo in the artifact name
[1], [2].
It's quite an easy thing to do to repackage a jar as a bundle ~ 5 min.
Look at [3].
Figures out we need to use the service mix artifact only
Hi Ioan,
Thx for this version 2.
What if we need to migrate to commons-configuration 1.9 to use a new
functionality of that particular version whereas
org.apache.servicemix.bundles.commons-configuration is only available
for 1.8.* [1]?
Will it break karaf integration?
Thx, Eric
[1]
http
Hello Eric,
Thanks for taking time for review.
On Wed, Feb 6, 2013 at 2:45 PM, Eric Charles wrote:
> It's possible to exclude the commons-configuration in the karaf module and
> add there the org.apache.servicemix.bundles.commons-configuration
> dependency.
I did something like that. I've built
It's possible to exclude the commons-configuration in the karaf module
and add there the org.apache.servicemix.bundles.commons-configuration
dependency.
I guess one day commons-configuration will be 'bundled'.
Thx, Eric
On 06/02/2013 12:34, Eric Charles wrote:
Hi Ioan,
I see commons-configu
Hi Ioan,
I see commons-configuration is removed in favor of
org.apache.servicemix.bundles.commons-configuration.
Is there no way to define that only for karaf distribution.
I don't see why the non-osgi part should depend on a servicemix
packaging. What if we want to update commons-configurati
Hello Devs,
I've made some progress regarding James-Karaf integration and I'm
ready to commit the work I've done in trunk. You can find the
change-set for review here [1].
To view a diff between trunk/karaf, check out [2] .
It adds the following under karaf folder:
* features - creates a Karaf f
19 matches
Mail list logo
