mavenization of some projects

[Bruno Oliveira]

Good morning peeps,

I'm working to mavenize these projects https://docs.google.com/drawings/d/1qNcbRsVUadjb8U4qHzh3KJx1iGxXVmTi84BeUAWMMV8/edit?usp=sharing

During the saga, I notice that krypt-core-java has a dependency on krypt-provider-jdk and also krypt-provider-jdk has a dependency on krypt-core-java. Is my understanding correct?

Because if the goal on krypt-core-java is have a dependency on krypt-provider-jdk to run the specs, maybe we should move the specs to krypt-provider-jdk?

I'll move forward with the maven-ish thing, just trying to understand the relation between these projects.

--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

[Martin Boßlet]

krypt-core-java shouldn't per se depend on krypt-provider-jdk. It should depend on *a* provider instead, and this dependence should only be needed to be fulfilled at runtime. Are there still parts in the code indicating a hard dependency? That's probably wrong, should be fixed then. When doing a 'gem install krypt' with JRuby, the krypt gem should pull in the krypt-core-java gem, which then in turn will pull in the krypt-provider-jdk gem by default. But things should still work if somebody decides to use a different provider gem other than krypt-provider-jdk. 

But you're right, the RubyJdk class [1] and other fragments are Rubyisms that should not be present in a pure Java provider library. I think we need to move those Ruby-specific parts to the first Ruby-aware library in the hierarchy, which in my opinion would be krypt-core-java (with the hierarchy being krypt-core-java depending on work-in-progress krypt-lib-java and also krypt-provider-jdk). It's gonna be challenging to make this all still work in the light that we want to maintain the flexibility of choosing different providers from Ruby. It's easier if the provider itself is a separate gem. If all things fail, we could of course still have a dedicated gem for the different providers, which would mainly consist of the current Rubyisms that expose the core krypt-provider-jdk.jar to Ruby world. Although I'd really love to find a less complicated way...

krypt-provider-x's themselves only depend on krypt-core-java for now because the Provider interface is declared there. We could loosen the coupling maybe by declaring the Provider interface in krypt-lib-java in the future? Thus keeping the dependency in pure Java code?

[1] https://github.com/krypt/krypt-provider-jdk/blob/master/src/org/jruby/ext/krypt/provider/jdk/RubyJdk.java

2013/5/4 Bruno Oliveira <br...@abstractj.com>

--
You received this message because you are subscribed to the Google Groups "krypt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to krypt-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bruno Oliveira]

Hi Martin, terrible sorry for the long delay to reply. Looks like it has
dependencies on it or I'm completely wrong.

Martin Boßlet wrote:
> krypt-core-java shouldn't per se depend on krypt-provider-jdk. It should
> depend on *a* provider instead, and this dependence should only be
> needed to be fulfilled at runtime. Are there still parts in the code
> indicating a hard dependency?

If we dig into the sources, looks like
https://github.com/krypt/krypt-core-java/blob/master/lib/krypt/core.rb#L38.
If I'm reading it correctly, not sure if this dependency was added for
testing purposes.

That's probably wrong, should be fixed
> then. When doing a 'gem install krypt' with JRuby, the krypt gem should
> pull in the krypt-core-java gem, which then in turn will pull in the
> krypt-provider-jdk gem by default. But things should still work if
> somebody decides to use a different provider gem other than
> krypt-provider-jdk.
>
> But you're right, the RubyJdk class [1] and other fragments are Rubyisms
> that should not be present in a pure Java provider library. I think we
> need to move those Ruby-specific parts to the first Ruby-aware library
> in the hierarchy, which in my opinion would be krypt-core-java (with the
> hierarchy being krypt-core-java depending on work-in-progress
> krypt-lib-java and also krypt-provider-jdk).

Please correct me, if I'm wrong, but krypt-core-java and krypt-lib-java
are pretty close, correct? Just wondering if krypt-lib-java is a
replacement to krypt-core-java or a new dependency (if it's a
dependency, at first glance seems a bit odd to me)

It's gonna be challenging
> to make this all still work in the light that we want to maintain the
> flexibility of choosing different providers from Ruby. It's easier if
> the provider itself is a separate gem. If all things fail, we could of
> course still have a dedicated gem for the different providers, which
> would mainly consist of the current Rubyisms that expose the core
> krypt-provider-jdk.jar to Ruby world. Although I'd really love to find a
> less complicated way...

+1 I'm really not sure if it's my lack of knowledge into the ecosystem.
But maybe we could make it simple trying to do some steps (I can be wrong)

- Eliminate rubyisms from the Java bits
- Maybe...maybe. Have krypt-provider-jdk and krypt-core-java in a single
project (less confuse)
- Add this project as a dependency and expose it into a gem

>
> krypt-provider-x's themselves only depend on krypt-core-java for now
> because the Provider interface is declared there. We could loosen the
> coupling maybe by declaring the Provider interface in krypt-lib-java in
> the future? Thus keeping the dependency in pure Java code?

Or merge it into a single project and expose interfaces to people plug
into a new provider. I'm still get in touch with the design on krypt, so
correct me if I'm saying something wrong.

Talking about mavenize the project, I've been working on it
(https://github.com/abstractj/krypt-core-java/commits/mavenish). Is a
quite simple configuration, but I have a couple of questions:

1. If you grab the sources and run mvn test, probably you will face with
this kind of issue: https://gist.github.com/abstractj/e25350214efd4ac998fb

Any clue? I tried to add krypt-provider-jdk, but I'm still trying to
figure out what's going on

2. Regarding the project tree

├── build_lib
│ ├── emma.jar
│ └── emma_ant.jar
├── krypt-core-java.gemspec
├── krypt-core-java.iml
├── lib
│ ├── krypt
│ │ └── core.rb
│ └── kryptcore.jar
├── nbbuild.xml
└── test
└── scratch.rb

Do we really need emma? How to generate kryptcore.jar (probably it will
be added on maven as dependency)? Could we move scratch.rb to the spec
folder?


>
> [1]
> https://github.com/krypt/krypt-provider-jdk/blob/master/src/org/jruby/ext/krypt/provider/jdk/RubyJdk.java
>
>
> 2013/5/4 Bruno Oliveira <br...@abstractj.com <mailto:br...@abstractj.com>>

>
> Good morning peeps,
>
> I'm working to mavenize these projects
> https://docs.google.com/drawings/d/1qNcbRsVUadjb8U4qHzh3KJx1iGxXVmTi84BeUAWMMV8/edit?usp=sharing
>
> During the saga, I notice that krypt-core-java has a dependency on
> krypt-provider-jdk and also krypt-provider-jdk has a dependency on
> krypt-core-java. Is my understanding correct?
>
> Because if the goal on krypt-core-java is have a dependency on
> krypt-provider-jdk to run the specs, maybe we should move the specs
> to krypt-provider-jdk?
>
> I'll move forward with the maven-ish thing, just trying to
> understand the relation between these projects.
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
> --
> You received this message because you are subscribed to the Google
> Groups "krypt-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to krypt-dev+...@googlegroups.com

> <mailto:krypt-dev%2Bunsu...@googlegroups.com>.

[Vipul Amler]

This looks good. :)

> 1. If you grab the sources and run mvn test, probably you will face with
> this kind of issue: https://gist.github.com/abstractj/e25350214efd4ac998fb
>
> Any clue? I tried to add krypt-provider-jdk, but I'm still trying to figure
> out what's going on
>

This is probably because of spec dependencies for now. We should try
to isolate them soon.

> 2. Regarding the project tree
>
> ├── build_lib
> │ ├── emma.jar
> │ └── emma_ant.jar
> ├── krypt-core-java.gemspec
> ├── krypt-core-java.iml
> ├── lib
> │ ├── krypt
> │ │ └── core.rb
> │ └── kryptcore.jar
> ├── nbbuild.xml
> └── test
> └── scratch.rb
>
> Do we really need emma? How to generate kryptcore.jar (probably it will be
> added on maven as dependency)?

I hope so thats what we should be doing.

Could we move scratch.rb to the spec folder?
>

Makes sense to move the scratch file.

> email to krypt-dev+...@googlegroups.com.

[Bruno Oliveira]

Hi friends, I'm back to the game and looks like I'm doing some progress
with mavenish branch
(https://github.com/abstractj/krypt-core-java/tree/mavenish)

Just grab the sources and run mvn clean test

Some considerations:

- One test will fail and I'm figuring out why:

INFO] Running RSpec tests from
/Volumes/hd2/opensource/security/krypt/krypt-core-java/spec
[INFO] ** spec/parser_factory_spec.rb
[INFO] ParserFactory
[INFO] can be instantiated - 0.006s
[INFO] instance
[INFO] creates PullHeaderParser - 0.006s
[INFO] ** spec/pull_header_parser_spec.rb
[INFO] PullHeaderParser
[INFO] returns parsed header - 0.031s FAILED

- The file scratch.rb was moved into the specs, but it isn't a spec. I
was just wondering if we could "rspecnize" that. Yes/No?

[Martin Boßlet]

2013/5/24 Bruno Oliveira <br...@abstractj.com>

Hi friends, I'm back to the game and looks like I'm doing some progress with mavenish branch (https://github.com/abstractj/krypt-core-java/tree/mavenish)

Just grab the sources and run mvn clean test

Awesome, thanks a lot!

 

 

Some considerations:

- One test will fail and I'm figuring out why:

INFO] Running RSpec tests from /Volumes/hd2/opensource/security/krypt/krypt-core-java/spec
[INFO] ** spec/parser_factory_spec.rb
[INFO]   ParserFactory
[INFO]     can be instantiated - 0.006s
[INFO]     instance
[INFO]       creates PullHeaderParser - 0.006s
[INFO] ** spec/pull_header_parser_spec.rb
[INFO]   PullHeaderParser
[INFO]     returns parsed header - 0.031s FAILED

Strange... I need to debug and have a closer look at this! Can't tell you what's happening :(

 

- The file scratch.rb was moved into the specs, but it isn't a spec. I was just wondering if we could "rspecnize" that. Yes/No?

Oops, 'scratch.rb' are normally just "Martinisms" and shouldn't be part of the official tests. My pattern here was to use a file called test/scratch.rb

that helps me attaching the debugger real quickly when I need to look deeper into particular code snippets. Anyway, the official tests should

all be RSpecs and the "test" directory for test/unit stuff isn't really used. I guess there's no need to "rspecnize" scratch.rb.

-Martin