Moving to the Maven forum would certainly address the most relevant
crowd :-).
On 3/16/2015 1:56 PM, Markus Karg wrote:
> There is not any magic in Maven at all. It is simply using tool plugins. You can define which ones you want to make the actual work, down to the 3rd digit of the version. So the problem is not coming from Maven itself, but from the POM author not declaring the actual providers wanted and / or using providers not installing the needed tools automatically. The latter is not the provider's fault, but mostly a legal issue.
>
> Can we *please* move this thread over to the Maven forum now as it is really off-topic? :-)
>
> -----Original Message-----
> From: Will Hartung [mailto:willh_at_mirthcorp.com]
> Sent: Montag, 16. März 2015 18:50
> To: users_at_glassfish.java.net
> Cc: Arun Gupta
> Subject: [gf-users] Re: Maven
>
> The problem with maven is that the pom file and source code do not a project make.
>
> You can have two people download the same project, and get different results in their build. Maven can badly suffer from the "works for me"
> issues of software development.
>
> The scary part of maven is the magic part -- and it's all magic. Since it's declarative, it's like ordering in a restaurant. You make a request of the "give me this result" instead of "do these steps, this way". The first way leaves much interpretation up to the service provider. In typical programming, it's mostly do what I say this way.
> With maven, if something is wrong, you're not asking right. And that can be extremely frustrating.
>
> Since maven delegates much of the responsibility for the project, OUTSIDE of the project, you end up with issues such as GF 3.1, which can NOT be built with the standard pom. It badly suffers from link rot, many of it's dependencies are simply not there, and difficult to find.
>
> While GF 4.x is nice, download the source, run maven, maven downloads the internet for you, in a few years, that may well not be the case.
> Versus having having the dependencies checked in with the project.
>
> That's a mixed bag as well.
>
> But that's my primary complaint with maven, your system is not your castle. I have no expectation that a maven build will "just work"
> because of all of the external dependencies.
>
> Regards,
>
> Will Hartung
> (willh_at_mirthcorp.com)
>
> On Mon, Mar 16, 2015 at 10:29 AM, Markus Karg <karg_at_quipsy.de> wrote:
>> Arun,
>>
>> sorry I just got angry reading that lot of nonsense about this very
>> appreciated tool. I think we should close this thread, as it is
>> off-topic anyways. :-)
>>
>> Regards
>> -Markus
>>
>> -----Original Message-----
>> From: Arun Gupta [mailto:arun.gupta_at_gmail.com]
>> Sent: Montag, 16. März 2015 16:24
>> To: Markus Karg
>> Cc: users_at_glassfish.java.net
>> Subject: Re: Maven
>>
>> Maven is as scary as any software is :)
>>
>> The issues with Maven are more talked about because of its excessive usage to build software. All my samples/demos, and most of Red Hat Java related workspaces, heavily rely upon on Maven anyway. So I don't think there is any need to defend for anybody!
>>
>> Arun
>>
>> On Mon, Mar 16, 2015 at 12:34 AM, Markus Karg <karg_at_quipsy.de> wrote:
>>> Arun and Wayne,
>>>
>>> I need to chime in here -- can't stand the unjustified Maven-bashing
>>> any longer! ;-)
>>>
>>> Maven in fact is the greates build tool I've ever seen, as it provides one single declarative solution to building any kind of project, independent of the platform and the IDE, which is great, as we have to deal with approximately 10 platforms and don't have the time to learn all compile switches of any fancy outdated product just to fix a bug. It even works with Delphi 1 (16 Bit), WiX, or InstallShield 10! We do not just need to "live with it", we should actually make it mandatory to everybody and stop to reinvent the wheel wrt build scripting each time a programmer is unhappy to read the Maven manual or take a class.
>>>
>>> I can't see anything that is "scary" with Maven (certainly it might have bugs just as any other software). It simply does what you tell it to do, but certainly you must know how to *correctly* tell it what that. Would be glad to to get an example what you mean with "scary", actually. As only project owners can upload to Maven Central, please complain with the particular product managers to get that fixed. Actually it is prohibited to upload unsigned JARs. But this has nothing to do with Maven as a tool! You don't even are forced use Maven Central but can use any other repository or download dependencies manually.
>>>
>>> Regards
>>> -Markus
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Arun Gupta [mailto:arun.gupta_at_gmail.com]
>>> Gesendet: Sonntag, 15. März 2015 03:14
>>> An: users_at_glassfish.java.net
>>> Betreff: [gf-users] Re: Java EE 7 Hands-on-Lab Updated (for You to
>>> Use)
>>>
>>> Wayne,
>>>
>>> See in line ...
>>>
>>> On Sat, Mar 14, 2015 at 4:06 PM, Wayne Pollock <pollock_at_acm.org> wrote:
>>>> It is a fine idea, well implemented. Yet, I do have concerns I'd
>>>> like to discuss.
>>>>
>>>> Too many of these tutorials rely on GUIs and/or maven. The result
>>>> is a lack of understanding of the underlying processes. I would
>>>> like to see *just one* "Hello EE world" tutorial that describes
>>>> compiling and deploying a WAR using nothing but javac and jar. Once
>>>> the basics of how EE works (the directory structure of a WAR, the
>>>> proper setting of CLASSPATH, etc.) is done, *then* is the time to go
>>>> on to teaching the Java EE technologies using automation and GUIs, if you wish.
>>>>
>>>> Maven scares me. As far as I can tell from the Google searching
>>>> I've done, the Maven central repository consists of unsigned contributed code.
>>>> The maven tool automatically downloads, installs, and runs such code.
>>>> I can't imagine how much longer it will be, before malware makes its
>>>> way into developers' PCs, and ultimately to servers, using maven as
>>>> an attack vector.
>>> Maven is indeed scary, but a pragmatic reality. So we all have to get
>>> used to it :)
>>>
>>> Have you looked at https://github.com/javaee-samples/javaee7-samples
>>> that shows Hello World samples for different Java EE 7 technologies?
>>> They can run against WildFly or GlassFish.
>>>
>>> There is also https://github.com/javaee-samples/javaee7-simple-sample
>>> that is a simple sample to showcase different Java EE 7 technologies.
>>>
>>>> Glassfish 4.1 scares me. I have reported the problem with it many
>>>> times, to a deafening silence. It contains bad/corrupted jars in
>>>> the official distribution, both from Oracle and from java.net. You
>>>> can't see the errors if you build using a GUI such as Netbeans, or using ant or maven.
>>>> But, add the javaee.jar to your CLASSPATH, and compile anything such as:
>>>>
>>>> class Foo {}
>>>>
>>>> with:
>>>>
>>>> javac -Xlint:all Foo.java
>>>>
>>>> and you will get about 20 warning messages about bad or missing jar
>>>> files. (I did make a bug report on this as well.) I am currently
>>>> switching my Java classes to use Wildfly. It's hard because, like
>>>> all Java EE servers, the Wildfly docs make no mention of how to
>>>> build code without using maven or some GUI IDE. They don't seem to
>>>> come with a javaee.jar, or equivalent.
>>> Have you looked at
>>> http://www.mastertheboss.com/jboss-server/wildfly-8/maven-configuration-for-java-ee-7-projects-on-wildfly?
>>>
>>>
>>> Arun
>>>
>>>> The new paradigm is "Devops". Developers need to understand
>>>> something about deployment, instrumenting code, logging, etc., in
>>>> addition to understanding CDI or Java messaging. They need to know
>>>> how to design file formats and message formats; many real-world
>>>> enterprise applications do use files along with databases. Your
>>>> tutorial should also address these issues, if possible.
>>>>
>>>> Finally, I would like tutorials to show correct security coding
>>>> practices, such as the proper normalization, sanitization, and
>>>> validation of external (untrusted, or "tainted") data. It's scary
>>>> that even today, the #1 vulnerability is SQL injections. Yet, try
>>>> to find any Java EE tutorials that do this, or any textbooks either.
>>>> I haven't found any. No wonder each new generation of programmers
>>>> makes the same errors.
>>>>
>>>> Thanks for the opportunity to vent a bit. Hopefully, you'll find my
>>>> arguments have at least a little bit of merit. If so, you don't
>>>> need to change the code; just add some comments here and there about
>>>> what was left out for the sake of clarity, with some pointers to
>>>> more information. As I said in the beginning, this is a good
>>>> tutorial and well implemented. I just think it can be improved to
>>>> give students a deeper understanding of Java EE development and
>>>> deployment, and of security best practices.
>>>>
>>>> --
>>>> Wayne Pollock
>>>>
>>>> On 3/13/2015 6:10 PM, Reza Rahman wrote:
>>>>> Folks,
>>>>>
>>>>> Many of you are probably already familiar with the official Java EE
>>>>> 7 Hands-on-Lab (https://glassfish.java.net/hol/). It is an
>>>>> excellent learning resource initiated Arun Gupta while still at
>>>>> Oracle. I just finished successfully delivering the lab once again at DevNexus 2015.
>>>>> In preparation for DevNexus and beyond I made a few
>>>>> updates/changes:
>>>>>
>>>>> * I tried to make the lab entirely self-directed and self-paced for
>>>>> attendees by removing as many possible stumbling blocks (however minor) as possible.
>>>>> * I updated the lab to use GlassFish 4.1 and NetBeans 8.0.2.
>>>>> * I polished up the code to make it as realistic as possible within
>>>>> the scope of a simple lab.
>>>>>
>>>>> The first bullet point above is what I would really like to bring your attention to.
>>>>> Every time I have run this lab I've tried to execute it such that
>>>>> it requires bare minimum or no involvement from me and in fact I
>>>>> believe I've succeeded in doing just that. The reason this really
>>>>> matters is that I think this lab material has much greater
>>>>> potential than just something else our team does at conferences. I
>>>>> believe that the lab is now in a state such that anyone can go
>>>>> through the lab entirely on their own, by just using the public HOL
>>>>> page. More importantly I think it is possible with very little
>>>>> effort for someone to lead the lab in their user group or company.
>>>>> I highly encourage you to do so if you have an interest in
>>>>> supporting the Java EE community. If needed, our team could provide any help that you may need (such as being present virtually or working with you one-on-one to get you prepared). I've supplied all the resources that you should need on the public HOL page.
>>>>>
>>>>> Do drop me a note off alias if you have any feedback on this, if
>>>>> there's anything that I can improve with the lab or if you need any
>>>>> help. For sake of completeness, I should mention that Arun also now
>>>>> has his own version of the lab
>>>>> (https://github.com/javaee-samples/javaee7-hol) that you should
>>>>> also take a look at if time permits.
>>>>>
>>>>> Cheers,
>>>>> Reza | Java EE Evangelist
>>>>> Cell: 267-798-9331
>>>>> Home Office: 215-736-1208
>>>>> Google/Skype: m.reza.rahman
>>>>> Twitter: @reza_rahman
>>>>> https://blogs.oracle.com/theaquarium/
>>>>> https://blogs.oracle.com/reza/
>>>>> https://cargotracker.java.net
>>>>>
>>>>> P.S.: In this same vein I'd like to point out that I've added
>>>>> detailed speaker notes to my version of our current flagship Java EE 8 talk:
>>>>> http://www.slideshare.net/reza_rahman/javaee8 (PowerPoint source
>>>>> available for download). Making use of this, you could deliver this
>>>>> talk yourself. As an example, Hanneli Tavante did this at ConFoo
>>>>> and Josh Juneau will be doing that soon at the Chicago Coder Conference.
>>>>> Of course talks are highly personal and I don't expect that anyone will just use my deck as-is (in fact neither Hanneli nor Josh are doing that).
>>>
>>>
>>> --
>>> http://blog.arungupta.me
>>> http://twitter.com/arungupta
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
> --
> This message, and any documents attached hereto, may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited.
> If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you for your cooperation.