Refurbish the maven1-fu build system to a modern one

bric3 / nCGLIB

CGLIB fork, to try things! ... well it's even harder than already thought !

Apache License 2.0

1 stars 1 forks source link

Refurbish the maven1-fu build system to a modern one #2

Open bric3 opened 12 years ago

bric3 commented 12 years ago

Maybe to gradle, but maven 2 / 3 will good as well.

Publishing the artifact to the maven central is not a priority.

abailly commented 12 years ago

Build is really simple AFAICT. Will have a look at it this afternoon.

bric3 commented 12 years ago

Yes indeed, what do you plan to do, going to maven or gradle ?

abailly commented 12 years ago

I do not know gradle so it would be much faster for me to go with maven. What do you think ?

bric3 commented 12 years ago

OK, it works for me :)

-- Brice

On Mon, Mar 26, 2012 at 06:18, Arnaud Bailly < reply@reply.github.com

wrote:

I do not know gradle so it would be much faster for me to go with maven. What do you think ?

Reply to this email directly or view it on GitHub: https://github.com/bryc3/nCGLIB/issues/2#issuecomment-4687704

abailly commented 12 years ago

Got a few questions on the build:

What about CI ? There is a cloudbees offering for FOSS projects: http://www.cloudbees.com/foss/index.cb
What about deployment? Can we host artifacts on github?

bric3 commented 12 years ago

Yes CI is an issue we could probably use the cloudbees offer, though at some point I think the library should probably be tested on JDK 5,6 and 7. I don't know if they offer the flexibility to run different test suite on different JDKs.

About deployment, it's not an issue right now, because we have to address other questions first:

I choose nCGLIB as the project name, but it's open for discussion.
It's a fork, but shall we keep the net.sf.cglib package as it's hosted on GitHub and as the project name is a bit different.
Having a target release backlog ?

abailly commented 12 years ago

Given, nCGLIB is not the sexiest name ever, yet I do not have a replacement right now. Will have to think a little,
Should probably changed, but what about Licensing issues? Does forking allows us to change the license (not that I would like to do that) and what happens with the original License? Is the original work not protected by its license in which case to what extent can we change it?
That would be great. What is the main missing feature of current cglib? Why would you want to use a newer version? I am personnally interested in replacing annotation-based stuff with dynamically generated objects, but YMMV.

bric3 commented 12 years ago

Yeah the name could wait.

I think renaming the package might be OK, as long as we distribute the license adn say it's a fork of CGLIB. Changing the license could be more tricky, however I just discussed with someone that knew a lawyer that actually work / worked in the opensource licensing. The actual license is an ASL 2, I don't know what this license imposes / restricts, it should be interesting to check on that.

Actually I would like to have the annotation stuff for the proxy factory, but dynamic generated objects could be interesting too, why not have both. For the first release, we could eventually mark it as alpha.