grunt-maven-plugin
grunt-maven-plugin copied to clipboard
allegro
Add Bower MavenRepository feature
I've added a system to be able to auto add bower dependencies from java dependecies that include a "bower" package. I'm open for change and i'd like to have some feedback and discuss about it.
This is interesting. Please take my comments as constructive. This could definitely be useful somewhere. My first thought is that It's similar to webjars.org. I like the idea of not needing the bower repo but instead using webjars/bowerjar. But the process needs to be seamless and easy. How do you create these jars? Why not use the webjar format?
I create the jar with just a few config in the resources plugin configuration to copy my src/main/javascript into META-INF/bower but i can easily use the META-INF/resources/webjars/ i didn't know the webjar format. I wanted to have feedback before adding stuff to help creating the jar without having to configure the resources plugin
Just as @tayloryork noted, format you are using needs to be well documented and there should be some tooling surrounding it as well (packaging, repository etc). I'm not sure creating and using specific bower packages format is still in scope of gmp.
I see the need behind making bower offline, as it hit me too many times, but maybe it could be achieved using some well-defined standard? We should settle this before going int technicalities of code itself.
Sure it needs more documentation, i think it would be good to handle natively the webjars also. I just wanted to initiate the discussion. I'm on freenode or reachable by email, or do you want to use only comment on this pull request ?
I think we could discuss it here for now, as we can use some feedback from other people, unless you have something against it.
So, since we are discussing the topic - can you write something more about the format you propose and why it should have it's place in grunt-maven-plugin?
For now the javascript are stored in META-INF/bower/ but being compatible with webjars is a good idea. All the file in META-INF/bower are consider as a bower component, and added to your bower.json dependencies. The main idea is to be able to package both backend and frontend code in the same repository.
I had first coded this as another plugin, but i see the grunt-maven-plugin more like a tool to connect java-maven with javascript world, as you not only run grunt but also bower, npm. So i thought it makes sense to have it there, and this way you also only need one plugin.
If anything, i think you should go with webjars - getting out there with something totally new yet very similar can be hard. I see that there is even some webjars maven plugin, but its scope is very basic (https://github.com/webjars/webjars-maven-plugin). I don't know how hard it will be to integrate webjars with bower. Maybe instead we should investigate bower local cache --offline mode in a manner similar to npm-offline goal? This would help maintain clean separation between Java and JavaScript (maven vs grunt).
Integrate the webjars on my plugin will be very easy. I'll do that today.
I've added this task also because some of the code can be held in a private maven repository so if you have all the java architecture for your project, you don't need to add another private bower repository. You keep your Java CI infrastructure
I didn't mean creating own bower repo, but using it's local cache feature in a similar way gmp uses npm node_modules cache to imitate offline mode. Archive bower cache, commit it with your code to freeze dependencies and use it in builds.
I've tried to explain the idea maybe a little bit better in my .md file, hope it helps
Okay, i see how it works and why it was made. But wouldn't it be better to use offline solution from bower-world instead of mixing bower with Java? To use bower cache so it does not need internet access? I'm just rather skeptic when it comes to managing JS via Java tools, while we already have native tools for this (namely bower and npm).
If you have a UserService that have frontend and backend code, using this solution permits you to only declare the dependency one time. If you have 2 separate projects for frontend and backend, i agree you dont need to use this kind of "task" but if you have only one project it helps. Because if your backend is in java usually you want package the application as just a single .war so you can deploy on EBS or Tomcat. What i do myself, is having AngularJS module come along with the REST API service, so i just need to create the templates.
Hm, but whatever you do with frontend code (like getting dependencies from bower or npm) it all ends up in WAR after its built. As i see it the only problem is offline capabilities so it can be built independently of any kind of shortage (i.e. github fail).
It’s more about having only one repository for private code, i still get all the public dependencies from normal bower dependencies. Maven also have its own local cache so both are handling the offline case.
Le 21 août 2014 à 22:34, Adam Dubiel [email protected] a écrit :
Hm, but whatever you do with frontend code (like getting dependencies from bower or npm) it all ends up in WAR after its built. As i see it the only problem is offline capabilities so it can be built independently of any kind of shortage (i.e. github fail).
— Reply to this email directly or view it on GitHub.
Ah, okay, now i get it :)
But isn't bower capable of pulling in dependency from any git repository? Don't you have some inner corporate git repository that can be used as private repo for bower?
Yes you can also use it this way but maybe a little harder to keep the link between the backend version and frontend version. Again, i m not saying that my way is the only way, just a way i found convenient for me, and maybe others :)
Le 21 août 2014 à 22:41, Adam Dubiel [email protected] a écrit :
Ah, okay, now i get it :)
But isn't bower capable of pulling in dependency from any git repository? Don't you have some inner corporate git repository that can be used as private repo for bower?
— Reply to this email directly or view it on GitHub.
Hm, but where is the link between backend and frontend version? For me ideally there should be no link - maven handles java, grunt (and bower) handles JS and i would be reluctant to put my JS dependencies in pom.xml, since we already have better native tools for that (which only lack offline stuff).
I need to be convinced about pulling in this request, so i can maintain and develop it in future :)
If i develop a new REST API, i want to have the JS controller ready also, so the API is ready to use in all my final apps. It is more if you have a team per feature and not a team for backend and a team for frontend. This way you provide a new REST API, it’s new controller and directive, and all the other team can use it with just upgrading in maven. In my philosophy the rest api should come with it’s JS implementation, so when you integrate a feature you only focus on how you want this feature to look like but not how it works.
Le 21 août 2014 à 22:47, Adam Dubiel [email protected] a écrit :
Hm, but where is the link between backend and frontend version? For me ideally there should be no link - maven handles java, grunt (and bower) handles JS and i would be reluctant to put my JS dependencies in pom.xml, since we already have better native tools for that (which only lack offline stuff).
I need to be convinced about pulling in this request, so i can maintain and develop it in future :)
— Reply to this email directly or view it on GitHub.
Okay, i see the merits of this approach (although i don't agree with them, since by publishing API in jar you make it unusble to purely frontend or python/ruby/... projects). Is it only about keeping same version in bower and maven or is publishing artifacts to nexus also a must?