jCompany - Relatos de uso

Pessoal, sei que tem alguns tópicos já sobre esta “plataforma”, mas gostaria mesmo de RELATOS de quem já utilizou, pois sabemos que, assim como a empresa que trabalho, muitas outras adquiriram este elefantinho branco. E somos, gentilmente, obrigados a trabalhar com eles.

  • Conseguiram mesmo fazer algo com ele?
  • Feliz ou infeliz com ele?

Dentre outras coisas que gostariam de dizer… :slight_smile:

em tempo, dispenso comentarios de pessoas que trabalham na POWERLOGIC.

Cara, eu trabalho com jCompany a 1 ano e meio…Versão Struts e versão JSF. Posso dizer que é um bom framework, e quando vc acostuma com ele e conhece a sua arquitetura as coisas se tornam bem simples. No caso do Struts é uma mão na roda… já em JSF nao há muita inovação…

Não trabalho na powerlogic e por varias vezes já fiquei puto com essa coisa…
mas hoje em dia vejo ele com outros olhos

Abrass

Primeiramente gostaria de dizer que nunca trabalhei com o jCompany, tudo que eu sei é pela boca de outras pessoas.

Bom quem já trabalhou com a “plataforma” diz que é uma ferramenta muito boa pra construir coisas báscas, mas quando temos que fazer algo que não está previsto ou que foge do comum ele se perde e o trabalho fica muito doloroso. Como todas as apps que desenvolvemos possuem características bem peculiares no geral, as pessoas reclamam muito dele.

Bom é isso,

Deixando claro novamnte que nunca meti a mão pra trabalhar com o jCompany não.

Minha empresa é parceira da POWERLOGIC e alguns projetos utilizamos o JCOMPANY 5.1.2 para ser exato, não gostei. mais se você deseja montar crud simples é bom utilizar ele sim.

Acho que o melhor para a empresa é contratar um Arquiteto de software para estudar e montar a sua própria arquitetura.
Pois o meu ponto de vista a Arquitetura dos sistemas devem ser feitos para se encaixar na empresa, não concordo com o fato de que seu usuário e seus programadores devem se adaptar a um componente externo.

Sem contar que antes de adotar o jcompany o gestor de tecnologia deve ter em mente que ficara “amarado” para sempre a POWERLOGIC, pois o mercado de profissionais de JCompany é muito menor que o mercado de programadores “normais”, que utilizam tecnologias que são padrões ao mercado de java.

Isso pode elevar muito o custo dependendo da necessidade do projeto.

Outra coisa que não gosto é como é vendido o produto.
Eles dizem que qualquer estagiário desenvolve um sistema com o JCompany, no meu ponto de vista só se o sistema for feito de CRUDs.
Caso contrario o estagiário deve conhecer todos os frameworks da arquitetura deles.(SEAM,FACES,HIBERNATE e outros mais).

Outra coisa que não gosto é que o pacote todo é muito muito muito lento e pesado.
Cada deploy é um parto.

Não indico!

Bom…

Vou colocar minha visão geral, sei que muitos vão achar que estou errado ou alguns achar que estou certo. Mas todo caso isto é um fórum onde cada um deve expressar sua opnião.

Visão:

O Framework jCompany é uma ótima ferramenta.
Ele possibilita a criação de pequenos casos de uso em instantes.

Mas ai podem estar se perguntando. E se eu tiver um sistema grande para ser desenvolvido???
Bom… vou colocar o que penso.

Acho que a powerlogic não criou o jCompany para ser uma ferramenta da série Polishop.

Daquelas que fazem tudo sozinho em um único framework. E que qualquer pessoa consegue fazer seu sistema em minutos.

Na realidade o jCompany facilita a criação de sistemas.

Vou dar um exemplo: Um sistema possui muitas telas de cadastros simples ex:

  • Clientes, Cidades, Estado, Fornecedores etc. (Esta parte o jCompany faz em instantes).

Mas mesmo assim é necessário que quem o utiliza seja um desenvolvedor.

Para casos de uso mais extensos, ele facilita novamente na criação.

Ele gera automaticamente o mapeamento das classes, possui arquivos de configuração para utilização de Actions
com mais facilidade, gera jsps, e possui métodos especificos para facilitar a vida do desenvolvedor.

Como dohko disse. A partir do momento que pegamos o jeito da sua arquitetura então, fica bom demais para trabalhar.

Eu conheço um gerador de código chamado Maker da Softwell, que ele sim promete que qualquer pessoa consiga criar um sistema
completo. Não tive a oportunidade de utilizar pois não existe versão demo. Só sei que é um sistema feito em Delphi (Na época)
que não gera códigos orientados a objetos (Por esse motivo já não curti) Gerar códigos java sem ser OO pra mim não rola.

Então esse é meu ponto de vista. Não sou funcionário da Powerlogic. Só trabalho com ele faz aproximadamente 2 anos.

Claro que não é mil maravilhas também mas como disse, se as pessoas que o utilizar, forem desenvolvedores java, que conheçam
JSF ou Struts, que possuem conhecimento em hibernate, servlets etc. conseguirá trabalhar com qualquer sistema não importa se for simples
ou robusto.

Mas pelo que eu escuto e vejo, ele é vendido assim. Esse é o problema.

[quote=foxpv][quote=natureza]
Acho que a powerlogic não criou o jCompany para ser uma ferramenta da série Polishop.
[/quote]

Mas pelo que eu escuto e vejo, ele é vendido assim. Esse é o problema.[/quote]

Esse é o maior problema.

[quote=dipeloco][quote=foxpv][quote=natureza]
Acho que a powerlogic não criou o jCompany para ser uma ferramenta da série Polishop.
[/quote]

Mas pelo que eu escuto e vejo, ele é vendido assim. Esse é o problema.[/quote]

Esse é o maior problema.[/quote]

Então… também concordo com vocês.

Mas acho que nós como desenvolvedores sabemos que isto não existe… Acho que se alguma empresa adquiri algo assim achando que faz tudo e a tiazinha do café pode desenvolver infelizmente quem peca são quem adquiri e não quem vende por não consultar alguem que entende da ferramenta.

Bom discussão a parte. Vai ser lançado um rally open-source utilizando a ferramenta jCompany.

O Intuito disso acho que é a busca de talentos. Mas acho que seria interessante.

Quem quiser manter informado este será o site.

Rally Java EE Open Source

Eu trabalho a quase dois anos com o jcompany mais antigo que teve que ser otimizado/marretado para suportar a aplicação. É até uma boa ferramenta para aplicações pequenas, agora para aplicações um pouco mais robustas deixa a desejar. Além de ser pago o que dificulta um pouco, o aprendizado não é fácil, e se você não utiliza o wizard fica tudo mais difícil pois não é intuitiva. O meu sentimento é que existem várias outras alternativas não pagas e com um grau de aprendizado relativamente baixo.

Galera,

trabalho hoje em dia com o jCompany 2.7.5 e o que vejo de bom é o struts que tem dentro dele e ele te auxilia na divisão das camadas de sua aplicação.
Só que tem umas coisas muito bizarras, tipo exceção calada, método que recebe um parametro que não é usado, todos as classes de entidade tem metodos aux’s,
tipo ‘getNomeAux()’ (pra mim se o metodo tem aux ja virou gambiarra). Tem uma classe interna aqui do framework que tem um código tipo

if(variavel.equals("1")){ //Tenta fazer algo }else if(variavel.equals("1")){ //Se não deu na primeira tenta de novo, quem sabe né? }
Sem contar que toda classe de um plc na frente. plcObjetoVO, plcMinhaClasse, plcPowerLogicVaiDominarOMundo.

Eu entrei no site da powerlogic para testar o jCompany 5.1 e lá diz que após criar o projeto [dar um new no eclipse] apresentará erros, no tutorial diz para dar um clean no eclipse e se não funcionar, dar um close e open no projeto.

Poderia listar outras coisas mas acho melhor parar por aqui.

Temos coisas bem melhores no mercado que são free e que pra mim são bem melhores, tipo Seam e Next.

Não quero brigar com quem gosta, só quero expressar a minha opnião.
Bem, é isso.
[]'s

plc? aux? pra que isso?
é obrigatório?

É obrigatório dependendo do aux ou do plc, mas o gerador gera pra você automagicamente. :stuck_out_tongue:

Boa pergunta !!! hehehehhe

[Moderado]

Já trabalhei com essa ferramenta… olhei código fonte… e tudo mais…

Minhas opiniões:

Começemos com os Plc*… tudo quanto é classe, atributo, qualquer coisa… começa com Plc… isso causa uma sujeira na aplicação…

Outra coisa, as entidades tem uma referencia para paiPlc… que coisa mais estranha é essa? O que vem a ser o paiPlc de um funcionário por exemplo? Qual é o seu paiPlc?

As entidades tem os atributos: detalhe1, detalhe2, detalhe3, detalhe4, detalhe5… Se quiser mais… tem que implementar toda a funcionalidade para um novo detalhe… sem contar que o nome nao é condizente (não dá pra saber o que é guardado em detalhe1)

Na versão que eu trabalhava, as entidades tinham informação até de CSS… é entidade com informação da view…

Proliferacao dos antes apos… tudo quanto é método tem um antesX e aposX… vc vai debugar…passa em várias camadas e vários antes apos… voce acaba se perdendo no que está acontecendo

Numa dessas de antes apos… um colega meu teve que fazer um upload… e teria que sobrescrever o método salvar do framework… tinha o antesSalvar e o aposSalvar… e o salvar era FINAL… teve que fazer uma alteração gigantesca por causa disso…

Tem uma fachada… que te obriga a chamar os métodos com String
Voce tem o xService por exemplo numa variavel… mas nao pode chamar o método diretamente tipo

Tem que ser

As exceções caladas explicadas num outro post também são causa de grandes problemas… dá um erro lá dentro do framewrok… a exceção cai em um catch… sem nada dentro…
Dá pau… nao acontece nada… nem uma mensagem no log… e você tem que debugar pra ver o que aconteceu

Isso são algumas coisas que eu lembro…

Ser uma versão antiga não justifica, pois… esses padrões adotados na ferramenta nunca foram aceitáveis

Tem algumas classes e atributos que nao segue nem o padrão de nomeclatura java…

Desculpa aí quem gosta… mas tive que expressar minha opinião…

Tem outras questoes também… mas não podem ser escritas aqui no fórum…

Não recomendo a ferramenta, nem para aplicações pequenas

Até mais

Háaa… os aux… tinha me esquecido

Na sua entidade … vc tem

Date dataNascimento; String dataNascimentoAux;

e as vezes vai embora

Date dataNascimento; String dataNascimentoAux; String dataNascimentoStr; String dataNascimentoStr2;

Então…

Tenho que lhe dizer que as versões novas a partir da 5.1 esta bem melhor.

Como disse não sou funcionário da powerlogic.

Sobre tudo estender algum PlcXXX é simples…

Ele é a classe pai responsavel por automatizações e facilidades. Sendo assim é impossivel fazer algo do tipo vindo do céu.

Anexar arquivos eu faço bem rápido sem estresse em sem todos esses passos que você citou.

Quer um exemplo?

Bom mas vou desconsiderar um pouco do que você disse porque tu tem um framework o qual você “criou” que inclusive parece muito bem e muito bem mesmo com o Spring MVC.

Mas todo caso deixa pra lá.

Abraço a todos…

Cara, de boa…

Eu ter criado ou não um framework, não tem nada a ver… com a crítica ao jCompany…

Inclusive, o único framework que voce vai me ver criticar … é o jCompany…

O jCompany 5.1 está melhor… com certeza… mas mesmo assim nao vale a pena… ele é só uma camada, sobre coisas que já existem…
E não adiciona nada, a não ser complexidade…

Apesar de ter trabalhado mesmo com uma versão mais antiga… conheço também essa versão mais nova…

Quando falei que tudo extende um PlcXXX… a critica foi inclusive ao nome PLC, nem foi em relação a herança… não faz sentido prefixar todas as classes com Plc…

Experimenta depois… trabalhar com o JBoss Seam sozinho… vai ser melhor do que com jCompany… no inicio talvez voce tenha um trabalho a mais para bolar uma arquitetura… mas no final vai compensar… (e olha que nem sou a favor do JBoss Seam também)
Você vai ver que o jCompany não faz nada além do que o jBoss seam já faz…

Sobre a semelhaça do meu framework com o Spring MVC… não é mera coincidência… ele é baseado no Spring e a parte controller dele baseado no Spring MVC…
De qualquer forma, isso é só uma parte do framework… ele não se resume a isso…

Não leve a mal minha crítica… mas experimente outras coisas…

Ja mexi com jBoss Seam.

Não estou falando que jCompany é perfeito mas também discordo de quem fale que ele é ruim igual você disse e falou que não recomenda nem para pequenas aplicações.

Agora criticar o Plc é piada não ter o que falar e falar que está criticando o PlcXXX.

É intuitivo a Powerlogic que para quem esta utilizando logo identifica que refere-se a uma super clase.

Bom também não vou ficar aqui discutindo… ja expressei minha opnião.

Se fosse ruim assim ninguem o compraria. Faça uma pesquisa de empresas que o utilizam.

Eu particularmente gosto, se parar de trabalhar com ele vou aprender o framework que vier se não tiver nenhum utilizamos o bloco de notas mesmo…

Como dizem em vários tópicos no fórum… Um desenvolvedor aprende a trabalhar com qualquer framework.

Certo? jCompany faz tudo que jBoss Seam ja faz = Next Faz tudo o que Spring MVC ja faz… Bingo !

Se eu for falar tudo do jCompany aqui… eu vou ferir as regras do fórum…

Isso… serve pra mim também

Sim… o jCompany é polishop… é só ver o marketing que existe nele…

Isso é gerador de código… não é inerente ao framework… e qualquer manutençao é um parto…

Acho que framework voce nao tem que pegar o jeito… pegar o jeito pra mim… é saber qual a gambiarra tem que fazer… para determinado problema (isso eu vejo bem no jCompany)

[quote]Anexar arquivos eu faço bem rápido sem estresse em sem todos esses passos que você citou.

Quer um exemplo? [/quote]

Não foi um upload trivial. De qualquer maneira o problema é que o método salvar era final, e precisava ser sobrescrito.

Opinião sua… perfeito… Eu tenho uma diferente…

Isso foi apenas uma das criticas que o framework recebeu… Tem um monte de outras coisas citadas…

Conheço quem utiliza… já que voce também conhece… Pense no que essas empresas que usam jcompany tem em comum… e porque elas utilizam…

A discussão não é sobre o Next… mas vou ter que me pronunciar aqui.
Se você quer estudar o Next a fundo, trabalhar com ele, para poder criticar eu entendo perfeitamente. Assim como eu fiz com o jCompany.
Mas não critique o que voce não conhece… Você está falando bobagem…
Primeiro, o Next tem funcionalidades que hoje são implementadas pelo Spring… tem sim… mas essas funcionalidades foram implementadas antes de elas existirem no Spring… ou seja… em que o Next é comum com o Spring… o Next foi pioneiro.
Como hoje o Spring implementa essas funcionalidades, o Next passará a responsabilidade para o Spring… e irá se restringir no que o framework oferece e o Spring não.
O Next oferece uma série de funcionalidades, que o Spring não possui e nao está nem no escopo dele.
Eu falei do jCompany porque eu conheço ele muito bem… e pelo visto mais do que voce… Então conheça as coisas… estude antes de falar qualquer coisa…


Quero me desculpar aqui pela discussão aos usuários do fórum que acham que discussões (religiosas) desse tipo não agregam valor a comunidade, eu também concordo com isso.
Só levei essa discussão mais a fundo porque considero que o jCompany não segue a mesma filosofia dos outros frameworks não visando uma boa ferramenta e sim lucratividade.
E minha opinião não foi respeitada.